Agentic Tool Loop: Saat Chatbot Perlu Bertindak, Bukan Cuma Bicara

Agentic Tool Loop: Saat Chatbot Perlu Bertindak, Bukan Cuma Bicara

RAG biasa (Retrieval-Augmented Generation — model dikasih bahan dari data sendiri sebelum menjawab) cuma bisa satu putaran: search sekali, kasih hasilnya ke model, dapat jawaban. Itu cukup untuk lookup sederhana. Tapi begitu permintaan butuh beberapa langkah — cari kandidat, ambil detail dua di antaranya, bandingkan, lalu susun jawaban akhir — satu putaran saja tidak cukup. Agentic tool loop dibangun untuk kasus itu: permintaannya rangkaian keputusan, bukan satu lookup. Agentic di sini artinya AI yang bisa mengambil tindakan, bukan cuma menjawab.

Bayangkan pelayan toko yang tidak cuma menjawab pertanyaan. Ia juga boleh mengambil barang dari gudang, mengeceknya, membandingkan dengan pesanan lain, baru menjawab. Itu bedanya agentic tool loop dengan chatbot biasa.

Tool sebagai fungsi bertipe, bukan aksi bebas

Model tidak diberi kebebasan penuh untuk "melakukan apa saja." Ia diberi menu tool yang tetap. Tiap tool punya nama, deskripsi kapan harus dipanggil, dan skema parameter yang ketat.

Di asisten klasifikasi regulasi yang saya bangun, menunya ada lima tool: cari kandidat kode, ambil detail satu kode, bandingkan dua sampai empat kode berdampingan, susun kode untuk bisnis dengan banyak aktivitas, dan audit daftar kode yang sudah dipunyai pengguna. Masing-masing membungkus logika deterministik yang sudah ada. Tool tidak memberi model ruang untuk mengarang jawaban — model cuma memilih operasi mana yang dijalankan, dan dengan argumen apa.

Batasan ini yang membuat sistem agentic tetap grounded. Tugas model sempit: baca percakapan, pilih satu dari lima operasi yang relevan, beri argumen yang valid. Semua yang terjadi setelahnya berjalan di atas kode yang Anda tulis dan bisa Anda audit, bukan di atas teks bebas karangan model.

Loop-nya, secara mekanis

Loop-nya sederhana. Model menerima percakapan plus menu tool. Ia bisa langsung menjawab, atau minta satu-dua tool dijalankan.

Kalau ia minta tool, sistem menjalankannya. Hasilnya ditambahkan kembali ke percakapan sebagai pesan tool, lalu semuanya dikirim ulang ke model untuk putaran berikutnya. Ini berulang sampai model menjawab tanpa panggilan tool lagi, atau sampai batas ronde tercapai dan loop memaksa jawaban akhir.

Batas ronde dipasang dengan alasan yang sama seperti deadline per giliran. Tanpanya, model yang mengejar query sulit bisa memanggil tool tanpa henti — habis waktu, habis uang, tidak pernah konvergen. Empat sampai lima ronde biasanya cukup untuk pertanyaan pengguna sungguhan. Kalau model belum konvergen sampai saat itu, memaksa jawaban dari apa yang sudah ada lebih baik daripada membiarkan loop jalan tanpa batas.

Guardrail per tool

Setiap panggilan tool adalah input yang tidak bisa dipercaya begitu saja, meski modelnya "orang sendiri." Validasi argumennya seperti Anda memvalidasi request dari klien eksternal: batasi ukuran array, tolak kode yang salah format, batasi rentang angka. Satu panggilan tool yang error tidak boleh menjatuhkan seluruh ronde. Tangkap errornya, kembalikan error terstruktur sebagai hasil tool itu, biarkan model melihat kegagalannya dan memutuskan langkah berikutnya.

Dua guardrail kecil lain juga layak dipasang. Pertama, dedupe panggilan yang berulang: model kadang meminta search yang sama dua kali lintas ronde. Simpan hasilnya dalam cache untuk sisa giliran itu — dihitung sekali, bukan sekali per permintaan.

Kedua, tandai tool tertentu sebagai terminal: tool yang hasilnya adalah jawaban itu sendiri (laporan audit, daftar tersusun) bisa langsung mengakhiri loop. Loop berhenti tanpa satu putaran generasi ekstra yang isinya cuma menyuruh model menulis ulang keluaran tool itu.

Framework vs. loop buatan sendiri

Agent framework memberi banyak hal siap pakai: skema tool, logika retry, streaming, kadang orkestrasi multi-agent. Untuk sistem dengan banyak jenis tool dan alur kerja terbuka, wajar menambah dependency seperti itu.

Tapi loop itu sendiri — panggil model, dispatch, tambahkan hasil, ulangi sampai selesai atau mentok batas — cukup pendek untuk ditulis sendiri. Menulisnya sendiri berarti Anda memegang tiap keputusan yang biasanya diambil framework: kapan persis satu panggilan dihitung ke batas ronde.

Anda juga menentukan bagaimana deadline berinteraksi dengan request yang sedang berjalan, dan tool mana yang memotong loop lebih awal. Kalau set tool Anda tetap dan kecil, seperti umumnya untuk satu asisten fokus, loop buatan sendiri lebih mudah dipahami dan diuji — daripada memikul abstraksi framework, lalu berkelahi dengannya cuma demi satu perilaku yang Anda butuhkan.

Kapan agentic mengalahkan RAG satu putaran

Pakai loop ketika permintaannya kompositional: butuh hasil satu langkah untuk memutuskan langkah berikutnya. "Kode KBLI apa yang cocok untuk bisnis pengembangan software sekaligus retail hardware" tidak bisa dijawab dari satu kali search — butuh minimal dua kali search dan aturan untuk menggabungkannya. "Cek sepuluh kode ini terhadap bisnis saya" butuh lookup per kode, penilaian relevansi per kode, dan perbandingan terhadap yang seharusnya dipunyai bisnis itu. Itu alur kerja multi-langkah sungguhan, bukan sekadar lookup.

RAG satu putaran tetap pilihan tepat untuk pertanyaan langsung dengan jawaban langsung. Lebih murah. Lebih cepat. Tidak ada yang perlu diulang.

Begitu hasil tool berputar balik ke model, guardrail yang mencegah jawaban salah yang percaya diri jadi makin penting. Begitu juga menjaga biaya panggilan model tiap ronde tetap murah — giliran agentic lima ronde melipatgandakan risiko halusinasi sekaligus biaya dari pilihan model yang ceroboh.