Artikel sebelumnya di blog ini pernah membahas function calling — mekanisme dasar yang membuat AI agent bisa benar-benar “melakukan” sesuatu, bukan cuma menjawab teks. Yang belum dibahas: begitu satu agent punya lebih dari satu tool untuk dipakai — cek stok, cek jadwal, kirim notifikasi, cari data pelanggan — bagaimana dia memutuskan tool mana yang harus dipanggil untuk permintaan tertentu? Ini yang disebut orchestration atau routing antar tools, dan di sinilah banyak agent yang kelihatan pintar di demo tapi berantakan di produksi.
Masalah yang muncul begitu tool bertambah banyak
Dengan satu atau dua tool, agent jarang salah pilih — hampir tidak ada ambiguitas. Begitu jumlah tool bertambah jadi delapan, sepuluh, atau lebih (cek stok toko A, cek stok toko B, buat invoice, kirim WhatsApp, jadwalkan reminder, cari riwayat pesanan), model mulai menghadapi keputusan yang lebih rumit: permintaan pelanggan yang ambigu bisa cocok dengan beberapa tool sekaligus, atau butuh dipanggil berurutan dengan urutan yang tepat (cek stok dulu, baru buat invoice, baru kirim konfirmasi).
Deskripsi tool yang buruk adalah sumber error paling umum
Kesalahan paling sering terjadi bukan karena modelnya “bodoh”, tapi karena deskripsi tool yang diberikan ke agent tidak jelas atau tumpang tindih. Kalau ada dua tool bernama “cek_stok” dan “cek_ketersediaan” dengan deskripsi yang mirip-mirip, agent bisa salah pilih, atau lebih buruk, memanggil keduanya secara tidak konsisten di percakapan berbeda. Prinsip praktisnya: nama dan deskripsi tool harus sejelas mungkin membedakan kapan masing-masing dipakai — semirip menulis dokumentasi fungsi untuk sesama programmer, bukan sekadar label internal.
Urutan pemanggilan sama pentingnya dengan pemilihan tool
Beberapa alur kerja butuh tool dipanggil dalam urutan tertentu — memverifikasi stok sebelum membuat pesanan, mengonfirmasi identitas pelanggan sebelum membuka data sensitif. Agent yang tidak dirancang eksplisit soal urutan ini bisa saja langsung “melompat” ke langkah akhir kalau modelnya menganggap itu cara tercepat menjawab permintaan — hasilnya invoice terbuat untuk stok yang ternyata sudah habis, atau data dibuka sebelum verifikasi selesai.
- Batasi jumlah tool yang aktif sekaligus per konteks percakapan — tidak semua tool perlu selalu tersedia di setiap alur.
- Tulis deskripsi tool yang eksplisit membedakan kapan dipakai, bukan sekadar nama teknis.
- Tegaskan urutan wajib untuk alur yang berisiko (verifikasi sebelum transaksi, konfirmasi sebelum eksekusi tindakan yang tidak bisa dibatalkan).
Kenapa ini bukan sekadar soal teknis internal
Dari sisi bisnis, kesalahan routing tool jarang terlihat sebagai “bug teknis” oleh pelanggan — yang terlihat justru sebagai agent yang tidak konsisten, kadang benar kadang salah tanpa pola yang jelas. Padahal akar masalahnya sering sesederhana dua tool dengan deskripsi yang membingungkan model. Kalau bisnis mulai menambah lebih banyak kemampuan ke agent yang sudah berjalan, mengecek ulang deskripsi dan urutan tool jadi langkah yang sama pentingnya dengan menambah tool baru itu sendiri — bukan langkah tambahan yang bisa dilewati.