Kapan agent AI harus berhenti? Mengatur biaya dan percobaan ulang untuk UMKM

Agent AI yang terus mencoba terdengar rajin sampai pemilik usaha melihat pekerjaan yang sama diproses berulang kali. Draf balasan belum selesai, biaya pemakaian bertambah, dan staf tidak tahu apakah harus menunggu atau mengambil alih. Masalahnya sering lebih sederhana daripada kemampuan model: sistem tidak punya aturan berhenti yang tegas.

Bagi UMKM, aturan itu perlu ditulis sebelum otomasi diberi akses bekerja. Anggaran yang terbatas membuat percobaan tanpa ujung cepat terasa. Pelanggan juga tidak peduli berapa banyak langkah yang sudah dijalankan agent; mereka menunggu hasil yang benar. Artikel ini membahas rancangan kendali operasional, bukan laporan penerapan pada usaha tertentu atau janji penghematan.

Tetapkan hasil akhir sebelum batas biaya

Misalkan sebuah toko ingin agent membantu menyiapkan jawaban atas pertanyaan ketersediaan barang. Dalam contoh hipotetis ini, tugas agent selesai ketika ada draf jawaban yang menyebut produk yang tepat, memakai informasi stok yang diperoleh dari sumber resmi toko, dan menandai informasi yang belum tersedia. Pengiriman ke pelanggan berada di luar cakupan.

Definisi tersebut memberi alasan konkret untuk berhenti. Agent tidak perlu terus mencari kalimat paling menarik setelah syarat isi terpenuhi. Jika data stok tidak bisa diambil, tugasnya berubah menjadi laporan kendala untuk staf, bukan menebak bahwa barang tersedia.

Anthropic dalam Building effective agents menyarankan solusi paling sederhana yang memenuhi kebutuhan. Tulisan itu membedakan workflow dengan alur yang ditentukan kode dari agent yang memilih langkahnya sendiri. Untuk pertanyaan stok yang polanya tetap, workflow sederhana mungkin sudah cukup. Kebebasan memilih langkah menambah kebutuhan pengawasan, bukan otomatis menambah manfaat.

Pisahkan anggaran uang, waktu, dan tindakan

Satu batas biaya model belum mencakup seluruh ongkos pekerjaan. Agent dapat memakai layanan pencarian berbayar, memanggil sistem lain, atau menyita waktu staf untuk memeriksa hasil. Sebaliknya, pekerjaan yang murah bisa tetap mengganggu jika pelanggan harus menunggu terlalu lama.

Rancang batas untuk setiap pekerjaan: batas pengeluaran, tenggat, jumlah langkah, dan jumlah percobaan ulang. Lalu tetapkan batas agregat bagi operasional usaha agar banyak pekerjaan kecil tidak menghabiskan anggaran bersama. Nilainya perlu mengikuti volume dan kemampuan bisnis, bukan menyalin angka dari demo orang lain.

Batas tersebut harus diperiksa oleh aplikasi atau pengendali eksekusi. Kalimat di prompt seperti “jangan boros” tidak cukup untuk menolak pemanggilan berikutnya. Jika tagihan layanan baru diketahui sesudah respons diterima, sistem perlu mencadangkan perkiraan biaya sebelum melanjutkan. Perkiraan itu tetap memiliki ketidakpastian dan harus dibandingkan dengan pemakaian aktual.

Pisahkan juga izin tindakan dari uang. Anggaran yang masih tersedia tidak memberi agent kewenangan mengirim pesan, mengubah pesanan, atau melakukan pembayaran. Semua tindakan itu memerlukan aturan izin tersendiri.

Percobaan ulang harus mengikuti jenis kegagalan

Tidak semua kegagalan layak dicoba lagi. Gangguan jaringan sementara mungkin pulih. Produk yang tidak ditemukan memerlukan klarifikasi. Penolakan akses harus menghentikan tindakan tersebut; mencoba jalur lain untuk melewati izin justru memperburuk keadaan.

Dalam contoh toko tadi, kegagalan membaca stok boleh mendapat percobaan ulang terbatas jika jenis gangguannya mendukung. Setelah batas tercapai, agent menyerahkan nama barang dan kendala kepada staf. Agent tidak perlu mengulang pencarian dengan variasi kata tanpa alasan yang bisa dijelaskan.

Kasus lebih sulit muncul ketika sistem tidak menerima jawaban setelah meminta perubahan data. Koneksi terputus tidak membuktikan perubahan gagal. Jika kelak otomasi diberi izin membuat dokumen bisnis, pengulangan tanpa pemeriksaan dapat membuat dokumen ganda. Karena itu, rancangan perlu menyediakan identitas operasi dan pemeriksaan hasil tersimpan sebelum memutuskan apakah pengulangan aman.

Ini adalah rekomendasi desain aplikasi. Dukungan terhadap pencegahan duplikasi bergantung pada layanan yang dipakai dan harus diuji, bukan diasumsikan tersedia di setiap tool agent.

Kenali pekerjaan yang bergerak tanpa kemajuan

Agent dapat tampak sibuk sambil berputar: membaca halaman yang sama, menulis ulang rencana, lalu memanggil pencarian serupa. Jumlah langkah yang bertambah tidak membuktikan ada kemajuan.

Simpan penanda kemajuan yang relevan dengan tugas. Pada contoh stok, penandanya bisa berupa produk sudah teridentifikasi, data stok berhasil dibaca, atau draf berhasil diperiksa terhadap sumber. Jika langkah berikutnya tidak membawa bukti baru, pengendali dapat menghentikan pekerjaan atau menyerahkannya kepada manusia sesuai aturan yang telah ditetapkan.

Anthropic menekankan pentingnya umpan balik dari lingkungan, termasuk hasil tool dan eksekusi kode, agar agent menilai kemajuannya. Dokumentasi tersebut juga menyebut kondisi berhenti seperti batas iterasi. Untuk pemilik usaha, implikasinya praktis: laporan agent harus menjelaskan hasil yang diperoleh, bukan hanya mengatakan bahwa ia telah bekerja keras.

Status berhenti harus berguna bagi staf

Jangan menyatukan semua pekerjaan ke dalam status “selesai” atau “gagal”. Staf perlu membedakan draf yang siap diperiksa, tugas yang menunggu informasi pelanggan, pekerjaan yang kehabisan anggaran, dan tindakan yang hasilnya belum dapat dipastikan.

Saat agent berhenti, tampilkan ringkasan pendek tentang apa yang berhasil dilakukan, alasan berhenti, serta langkah aman berikutnya. Untuk contoh toko, ringkasannya dapat menyebut bahwa produk sudah ditemukan tetapi data stok belum bisa dibaca, sehingga staf perlu mengecek sistem sebelum menjawab pelanggan.

Hindari memasukkan seluruh percakapan dan data pelanggan ke notifikasi operasional. Detail untuk audit dapat disimpan dengan hak akses serta retensi yang sesuai. Orang yang mengambil alih perlu konteks secukupnya, bukan salinan semua data yang pernah dilihat model.

Penghentian juga tidak selalu membatalkan tindakan yang sudah terjadi. Jika pesan telah terkirim, tombol berhenti hanya dapat mencegah langkah berikutnya. Antarmuka harus menjelaskan perbedaan itu agar staf tidak mengira keadaan lama sudah pulih.

Batas akses tetap diperlukan meskipun ada anggaran

OWASP menjelaskan Excessive Agency sebagai risiko akibat fungsi, izin, atau otonomi yang berlebihan. Salah satu contoh yang dibahas adalah koneksi yang memiliki izin mengubah data padahal tugasnya hanya membaca.

Untuk tahap awal contoh toko, tool pembaca stok dan pembuat draf cukup masuk akal. Akses untuk menghapus barang atau mengubah transaksi tidak diperlukan. OWASP juga menganjurkan persetujuan manusia untuk tindakan berdampak tinggi dan penegakan otorisasi pada sistem tujuan, bukan menyerahkan keputusan izin kepada model.

Pembatasan laju dapat mengurangi banyaknya tindakan yang tidak diinginkan dalam suatu periode. Namun, seperti diingatkan OWASP, pembatasan tersebut membatasi dampak, bukan menghilangkan penyebab Excessive Agency. Satu tindakan tanpa izin tetap bermasalah meskipun biayanya murah dan hanya terjadi sekali.

Uji jalan berhenti sebelum menambah otomatisasi

Sebelum dipakai, jalankan skenario data tidak lengkap, sumber tidak tersedia, respons terlambat, dan tugas yang mengulang langkah tanpa kemajuan. Periksa apakah batas benar-benar menolak tindakan berikutnya, apakah staf menerima alasan yang jelas, dan apakah pekerjaan bisa dilanjutkan tanpa mengulang tindakan yang sudah terjadi.

Catat waktu penyelesaian, pemakaian layanan, dan seberapa sering staf harus memperbaiki draf. Pisahkan pengamatan uji dari perkiraan. Jika batas terlalu ketat membuat banyak tugas sederhana berhenti, perbaiki alurnya terlebih dahulu sebelum menaikkan anggaran.

Otomasi yang layak dipakai sehari-hari memberi pemilik usaha cara untuk memahami kapan pekerjaan selesai dan kapan bantuan manusia diperlukan. Mulailah dari satu tugas baca-dan-draf, lalu uji penghentiannya. Tambahkan kewenangan setelah hasilnya bisa diperiksa dan batasnya terbukti bekerja.

Sumber

• Anthropic, Building effective agents: pemilihan workflow atau agent, umpan balik lingkungan, dan kondisi berhenti.
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency: batas fungsi dan izin, persetujuan, otorisasi sistem tujuan, serta pembatasan dampak.

Bacaan terkait: Agentic Web Application: Merancang Aplikasi yang Bekerja untuk Pengguna.