Tujuh Komponen Workflow AI Agent yang Perlu Dirancang Sebelum Memilih Platform

Platform bisa diganti. Workflow yang sejak awal salah desain akan tetap membawa masalah yang sama ke platform berikutnya.

Diskusi tentang AI agent sering langsung loncat ke model, framework, biaya token, kemampuan browser, atau jumlah integrasi. Semua itu penting, tetapi datang setelah satu pertanyaan yang lebih mendasar: pekerjaan apa yang sebenarnya mau lo serahkan kepada agent, dan seperti apa proses yang dianggap benar?

Platform yang canggih tidak otomatis menghasilkan workflow yang bisa diandalkan. Kalau tujuan pekerjaannya kabur, sumber datanya tidak jelas, atau agent bebas mengambil tindakan tanpa batas, mengganti platform biasanya hanya memindahkan masalah.

Ada tujuh komponen yang perlu dirancang lebih dulu: tujuan dan pemicu, konteks dan profil, instruksi dan alur, memory dan status pekerjaan, tool dan tindakan, batas perilaku dan persetujuan, serta evaluasi dan hasil.

Ketujuhnya saling mengunci. Satu komponen yang kabur bisa membuat enam komponen lain terlihat bekerja, padahal hasil akhirnya tetap tidak layak dipakai.

1. Tujuan dan Pemicu

Mulai dari dua pertanyaan: hasil akhir apa yang harus diserahkan, dan apa yang memulai pekerjaannya?

Tujuan perlu cukup spesifik untuk diperiksa. Instruksi seperti “bantu tim operasional” terlalu luas. Agent tidak tahu pekerjaan mana yang harus diprioritaskan, kapan pekerjaan dianggap selesai, atau dalam bentuk apa hasilnya harus diserahkan.

Bandingkan dengan instruksi berikut:

Setiap meeting selesai, siapkan ringkasan keputusan dan daftar action items untuk diperiksa oleh meeting owner.

Kalimat tersebut belum sempurna, tetapi sudah memberi bentuk pada pekerjaan. Ada waktu mulai, hasil yang diminta, dan pihak yang akan memeriksa.

Pemicunya dapat berupa:

• perintah langsung dari pengguna;
• jadwal harian atau mingguan;
• meeting yang baru selesai;
• file baru yang masuk ke folder tertentu;
• formulir yang baru dikirim;
• perubahan status pada CRM atau project tracker.

Pemicu juga perlu membawa konteks awal yang benar. Agent laporan mingguan, misalnya, harus tahu periode mana yang sedang dilaporkan. Salah satu tanggal saja bisa bikin seluruh laporan terlihat meyakinkan padahal memakai data yang keliru.

2. Konteks dan Profil

Agent bekerja untuk siapa? Produk, tim, pelanggan, dan aturan bisnis apa yang perlu dipahami?

Konteks bukan sekadar kumpulan dokumen yang dimasukkan ke prompt. Ia mencakup informasi yang membuat agent bisa menafsirkan pekerjaan dengan benar, seperti:

• tujuan dan batas tanggung jawab tim;
• definisi istilah atau metrik internal;
• gaya komunikasi yang digunakan;
• template keluaran;
• sumber data yang dianggap resmi;
• pihak yang berhak memberi keputusan;
• aturan bisnis yang tidak boleh dilanggar.

Bayangkan agent diminta membuat laporan pertumbuhan. Istilah “pengguna aktif” bisa berarti pengguna yang login, menjalankan fitur utama, atau menyelesaikan transaksi. Kalau definisinya tidak lo berikan, agent mungkin memilih definisi sendiri dan menghasilkan angka yang tidak bisa dibandingkan dengan laporan perusahaan.

Konteks yang baik membantu agent memahami pekerjaan. Konteks yang berlebihan justru menambah gangguan. Berikan informasi yang relevan dengan keputusan yang harus dibuat, bukan seluruh isi penyimpanan perusahaan.

3. Instruksi dan Alur

Setelah tujuan dan konteks jelas, petakan langkah kerja yang harus dijalankan.

Alur sebaiknya menjawab:

1. Data apa yang perlu diambil?
2. Dari mana data tersebut berasal?
3. Pemeriksaan apa yang harus dilakukan?
4. Bagaimana hasilnya disusun?
5. Siapa yang memeriksa hasilnya?
6. Kapan agent boleh melanjutkan atau harus berhenti?

Alur kerja yang matang tidak hanya menggambarkan kondisi ideal. Ia juga menjelaskan apa yang harus dilakukan ketika masukan tidak lengkap, tool gagal, data saling bertentangan, atau persetujuan belum diberikan.

Untuk agent meeting, alur sederhananya bisa seperti ini:

1. Ambil transcript dan metadata meeting.
2. Identifikasi keputusan, pertanyaan terbuka, dan action items.
3. Periksa apakah setiap action item memiliki PIC dan deadline.
4. Tandai informasi yang belum lengkap tanpa mengarang isinya.
5. Buat draft ringkasan.
6. Kirim draft kepada meeting owner untuk diperiksa.
7. Distribusikan hasil hanya setelah mendapat persetujuan.

Urutan ini bikin perilaku agent lebih mudah dipahami dan diuji daripada satu prompt panjang yang meminta agent “mengurus semuanya”.

4. Memory dan Status Pekerjaan

Memory sering dianggap sebagai tempat menyimpan sebanyak mungkin informasi. Padahal pertanyaan yang lebih berguna adalah: informasi apa yang benar-benar dibutuhkan lagi?

Bedakan setidaknya dua jenis penyimpanan:

• Status pekerjaan, yaitu informasi yang dibutuhkan selama satu proses berlangsung, seperti langkah terakhir, persetujuan yang masih ditunggu, atau file yang sedang diproses.
• Long-term memory, yaitu informasi yang masih berguna untuk pekerjaan berikutnya, seperti preferensi format, keputusan yang masih aktif, atau aturan yang telah disepakati.

Keputusan, PIC, deadline, dan preferensi format mungkin layak disimpan. Transcript lengkap dari setiap meeting belum tentu perlu menjadi long-term memory.

Makin banyak informasi yang disimpan, makin besar juga beban untuk memperbarui, mencari, mengamankan, dan menghapusnya. Memory bukan gudang. Simpan hanya informasi yang relevan, aman, punya masa berlaku yang jelas, dan benar-benar akan dipakai lagi.

5. Tool dan Tindakan

Agent membutuhkan tool untuk membaca data atau melakukan tindakan. Tool tersebut bisa berupa API, database, browser, file, email, kalender, Slack, Telegram, CRM, atau aplikasi internal.

Hal pentingnya adalah membedakan kemampuan membaca dan kemampuan mengubah sesuatu.

Membaca kalender memiliki risiko yang berbeda dari membuat atau membatalkan jadwal. Membaca draft email berbeda dari mengirimkannya ke pelanggan. Mengambil data CRM berbeda dari mengubah status deal.

Pakai prinsip akses minimum: agent hanya menerima akses yang diperlukan untuk menyelesaikan pekerjaannya. Kalau agent cuma bertugas membuat draft, ia tidak membutuhkan izin publish. Kalau agent hanya membuat laporan, ia mungkin tidak membutuhkan akses tulis ke sumber data.

Untuk setiap tool, dokumentasikan:

• data atau tindakan yang tersedia;
• input yang dibutuhkan;
• bentuk hasil yang dikembalikan;
• kemungkinan error;
• apakah tindakan tersebut dapat dibatalkan;
• apakah pengguna perlu memberi persetujuan.

Dengan begitu, tool tidak diperlakukan sebagai kotak hitam yang selalu berhasil.

6. Batas Perilaku dan Persetujuan

Batas perilaku menjelaskan batas tindakan agent. Persetujuan menentukan tindakan mana yang harus menunggu keputusan manusia.

Instruksi “jangan melakukan hal berbahaya” terlalu abstrak. Agent membutuhkan aturan yang operasional: kapan harus berhenti, bertanya, membuat draft, menawarkan retry, atau menyerahkan pekerjaan kepada manusia.

Tindakan berikut biasanya membutuhkan kontrol lebih kuat:

• mengirim pesan kepada pihak eksternal;
• mempublikasikan konten;
• mengubah atau menghapus data penting;
• menjalankan transaksi;
• memberikan akses kepada pengguna lain;
• membuat keputusan yang berdampak pada pelanggan.

Risiko juga dipengaruhi oleh kemampuan pemulihan. Membuat draft yang bisa dihapus relatif aman. Mengirim email massal atau menghapus data produksi jauh lebih sulit dibatalkan.

Batas perilaku yang baik tidak cuma melarang. Ia memberi jalur alternatif. Kalau data kurang, agent meminta data tambahan. Kalau tool gagal, agent mencatat kegagalan dan menawarkan percobaan ulang. Kalau tindakan membutuhkan persetujuan, agent menyiapkan pratinjau yang bisa diperiksa manusia.

7. Evaluasi dan Hasil

Komponen terakhir adalah menentukan seperti apa hasil yang benar dan bagaimana cara memeriksanya.

Tanpa evaluasi, agent memang menghasilkan sesuatu, tetapi lo tidak punya dasar yang konsisten untuk menilai apakah hasil tersebut layak dipakai.

Untuk ringkasan meeting, kriteria keberhasilan dapat berupa:

• semua keputusan penting tercatat;
• setiap action item memiliki PIC dan deadline;
• informasi yang belum tersedia ditandai sebagai belum lengkap;
• tidak ada nama, keputusan, atau tenggat yang dikarang;
• format mengikuti template tim;
• hasil telah diperiksa oleh meeting owner sebelum didistribusikan.

Evaluasi tidak harus selalu berupa skor otomatis. Daftar periksa, pemeriksaan sampel secara manual, perbandingan dengan sumber, dan persetujuan manusia tetap berguna. Yang penting, kriteria keberhasilan sudah ditentukan sebelum agent dijalankan secara luas.

Hasil juga perlu memiliki kontrak yang jelas. Kalau hasil akan diteruskan ke sistem lain, tentukan kolom, format, dan nilai yang wajib ada. Kalau hasil ditujukan kepada manusia, tentukan struktur yang membantu mereka memeriksa dan mengambil keputusan.

Uji Ketujuh Komponen sebagai Satu Sistem

Ketujuh komponen ini tidak bisa dinilai secara terpisah.

Misalnya, agent gagal membuat laporan. Penyebabnya belum tentu model yang digunakan kurang pintar. Bisa jadi pemicu memilih periode data yang salah, konteks tidak memuat definisi metrik, tool hanya bisa membaca sebagian sumber, atau evaluasi tidak menjelaskan pemeriksaan yang wajib dilakukan.

Karena itu, saat hasil agent meleset, trace lagi alurnya:

1. Apakah tujuan dan pemicunya benar?
2. Apakah konteks yang dibutuhkan tersedia?
3. Apakah instruksi menggambarkan alur normal dan kondisi gagal?
4. Apakah memory menyimpan status pekerjaan yang relevan?
5. Apakah tool memiliki akses dan respons yang tepat?
6. Apakah batas perilaku menghentikan tindakan berisiko?
7. Apakah evaluasi benar-benar mengukur hasil yang diinginkan?

Jangan langsung mengganti model atau menambah prompt. Perbaikan yang tepat bergantung pada komponen mana yang gagal.

Platform Datang Belakangan

Tujuh komponen ini dapat diterapkan pada platform yang berbeda. Nama fitur dan cara implementasinya mungkin berubah, tetapi pertanyaan desainnya tetap sama.

Mulai dari hasil yang dituju. Petakan alur. Berikan konteks dan tool secukupnya. Simpan memory yang benar-benar berguna. Batasi tindakan berisiko. Tentukan cara menilai hasil.

Setelah fondasi tersebut jelas, pemilihan platform menjadi keputusan yang lebih rasional. Lo bisa membandingkan tool berdasarkan kebutuhan alur kerja, bukan sekadar daftar fitur atau tren terbaru.

Sebelum mulai membangun, gunakan checklist singkat ini:

• Tujuan dan hasil akhir dapat diperiksa.
• Pemicu dan masukan awal sudah jelas.
• Konteks berasal dari sumber yang dipercaya.
• Alur mencakup kondisi normal dan kondisi gagal.
• Memory memiliki tujuan dan masa berlaku.
• Setiap tool mendapat akses minimum.
• Tindakan berisiko membutuhkan persetujuan.
• Hasil memiliki format yang jelas.
• Kriteria keberhasilan dapat diuji secara konsisten.

Checklist itu bukan administrasi sebelum build. Ia adalah cara memastikan kemampuan model benar-benar diarahkan ke pekerjaan yang bisa diperiksa, dibatasi, dan diperbaiki.

Agent yang berguna bukan sekadar model yang bisa memanggil tool. Ia adalah alur kerja yang punya tujuan, batas tindakan, dan cara evaluasi yang jelas.

Mau Membawanya ke Workflow Nyata?

Pilih satu pekerjaan, lalu periksa dengan tujuh komponen tadi. Bagian yang belum bisa dijawab adalah pekerjaan desain berikutnya, bukan alasan untuk buru-buru menambah tool.

Di Building AI Employees, lo akan menerapkan tujuh komponen ini untuk memetakan satu pekerjaan nyata sebelum membangun agent-nya.

Lo akan merancang alur, tools, persetujuan, kondisi gagal, dan cara menguji hasilnya sebagai satu sistem.

Lihat detail Building AI Employees.