Tool calling dapat mengubah chatbot menjadi agent yang benar-benar melakukan pekerjaan.
Tetapi begitu agent memperoleh kemampuan mengirim email, memperbarui database, membuat transaksi, atau menjalankan kode, standar reliability-nya harus meningkat drastis.
Dalam kondisi production, Menggunakan Tool Calling bukan hanya masalah apakah model berhasil memilih fungsi yang tepat.
Developer juga harus memikirkan timeout, duplicate execution, permission, retry, audit trail, latency, serta kemampuan mengetahui mengapa agent memanggil sebuah tool.
Sistem yang baik mengasumsikan kegagalan akan terjadi dan sudah menyiapkan mekanisme recovery sejak awal.
1. Anggap Tool Call sebagai Distributed System Operation
Tool call sebenarnya memiliki banyak karakteristik yang sama dengan komunikasi antarservice.
Agent membuat request, service memprosesnya, network dapat gagal, response bisa terlambat, dan client mungkin tidak tahu apakah action berhasil atau tidak.
Bayangkan agent memanggil fungsi create_payment. API sebenarnya berhasil membuat pembayaran, tetapi koneksi timeout sebelum response diterima.
Jika agent langsung retry tanpa mekanisme pengaman, pembayaran dapat terjadi dua kali.
Karena itu, reliability tool calling harus mengikuti praktik distributed systems, bukan hanya prompt engineering.
Gunakan timeout yang jelas, transaction ID, status terstruktur, dan mekanisme untuk mengecek hasil operasi sebelum mencoba kembali.
2. Gunakan Idempotency untuk Action Sensitif
Idempotency berarti request yang sama dapat dikirim lebih dari sekali tanpa menghasilkan efek tambahan yang tidak diinginkan.
Ini sangat penting untuk tool seperti pembayaran, pembuatan pesanan, pengiriman notifikasi, atau pembuatan tiket.
Misalnya setiap tool call create_order membawa idempotency_key.
Jika request pertama sebenarnya berhasil tetapi response hilang, retry dengan key yang sama akan mengembalikan order sebelumnya, bukan membuat order kedua.
Action read-only biasanya tidak membutuhkan kontrol seketat ini. Namun write operation yang memiliki efek bisnis sebaiknya dirancang dengan asumsi retry bisa terjadi kapan saja.
AWS mendefinisikan action groups sebagai kumpulan tindakan yang dapat dilakukan agent melalui API atau fungsi yang sudah ditentukan. Struktur tersebut memisahkan keputusan agent dengan implementasi aksi pada aplikasi.
Pemisahan itu memungkinkan reliability logic tetap berada di service layer.
3. Terapkan Retry Hanya untuk Error yang Tepat
Tidak semua error boleh di-retry.
NETWORK_TIMEOUT mungkin layak dicoba kembali.
INVALID_ACCOUNT_NUMBER jelas tidak.
INSUFFICIENT_PERMISSION juga tidak akan selesai hanya dengan mengulangi request lima kali.
Buat klasifikasi error menjadi retryable dan non-retryable.
Google ADK menunjukkan penggunaan retry configuration pada model dalam contoh project structure, sementara praktik agent secara umum juga membutuhkan pengendalian kegagalan pada setiap dependency yang digunakan.
Untuk temporary failure, gunakan exponential backoff dan batasi jumlah percobaan.
Setelah batas terlewati, agent dapat menggunakan fallback, meminta pengguna mencoba lagi, atau mengeskalasi kepada manusia.
Infinite retry bukan reliability. Itu hanya mengubah satu kegagalan menjadi biaya yang lebih besar.
4. Terapkan Permission di Luar LLM
Jangan membuat permission hanya sebagai instruksi:
“Jangan pernah menghapus pelanggan VIP.”
Model bukan authorization server.
Backend harus mengecek identity, role, tenant, action, serta resource yang ingin diakses sebelum menjalankan fungsi.
Misalnya sales agent boleh menggunakan get_customer_profile, tetapi delete_customer tidak pernah masuk ke tool set-nya. Finance agent dapat melihat invoice tertentu, tetapi tidak otomatis mendapat akses ke semua rekening bisnis.
Microsoft Agent Framework saat ini menempatkan security, tool approval, governance hooks, observability, dan evaluation sebagai kemampuan operasional yang terpisah dari reasoning agent.
Ini merupakan desain yang sehat: model mengusulkan action, sedangkan sistem menentukan apakah action tersebut memang diizinkan.
5. Tambahkan Human Approval untuk High-Impact Tool
Beberapa action terlalu berisiko untuk dijalankan hanya berdasarkan keputusan model.
Contohnya transfer uang, membatalkan kontrak, menghapus data permanen, atau melakukan perubahan pada sistem production.
Untuk kasus seperti ini, tool calling dapat menggunakan pola prepare → approve → execute.
Agent terlebih dahulu menyiapkan action lengkap dengan parameter. Sistem menampilkan ringkasan kepada manusia. Setelah mendapat approval eksplisit, barulah backend mengeksekusi tool.
Microsoft mendukung tool approval sebagai pola human-in-the-loop pada agent framework.
Dengan pendekatan tersebut, manusia tidak harus ikut campur pada seluruh workflow.
Agent tetap dapat mencari data, melakukan analisis, dan menyiapkan tindakan secara otomatis. Approval hanya muncul tepat sebelum keputusan kritis.
6. Gunakan Sandbox untuk Tool Eksekusi Kode
Tool yang dapat menjalankan code mempunyai tingkat risiko khusus.
Code execution membuka kemungkinan akses file, penggunaan resource berlebihan, serta tindakan yang tidak diinginkan jika lingkungan tidak dibatasi.
Google ADK menyediakan code execution melalui sandbox environment. Dokumentasinya menjelaskan bahwa AI-generated code dijalankan pada lingkungan terisolasi, sementara state dapat dipertahankan selama sesi untuk mendukung pekerjaan multi-langkah.
Prinsip ini berlaku lebih luas.
Jangan memberikan shell access langsung ke host production hanya karena agent membutuhkan kemampuan menjalankan analisis Python.
Batasi filesystem, network, CPU, memory, lifetime, secret access, dan permission sandbox sesuai kebutuhan.
Semakin powerful sebuah tool, semakin ketat isolation yang diperlukan.
7. Catat Tool Call sebagai Trace, Bukan Sekadar Log
Untuk agent sederhana, log seperti “request berhasil” mungkin terlihat cukup.
Di production, tim perlu mengetahui trajectory lengkap.
Catat tool yang dipilih, waktu pemanggilan, latency, status, retry, approval, error category, dan final outcome. Parameter sensitif harus disamarkan sesuai kebijakan keamanan.
Microsoft Agent Framework memasukkan observability berupa traces, metrics, dan logs sebagai capability untuk mengoperasikan agent.
Dengan trace seperti ini, developer dapat menjawab:
Mengapa agent memanggil cancel_order?
Apakah tool itu dipanggil dua kali?
Berapa lama API menunggu?
Apakah pengguna memberikan approval?
Tanpa trace, debugging agentic workflow akan terasa seperti menebak-nebak.
8. Evaluasi Tool Selection secara Terpisah
Jawaban akhir yang benar tidak selalu berarti agent bekerja secara efisien.
Agent mungkin berhasil memberi status pesanan setelah memanggil tujuh tool, padahal hanya satu yang diperlukan.
Karena itu, buat evaluation dataset yang memeriksa tool selection accuracy.
Untuk setiap request, tentukan tool yang seharusnya dipilih, parameter yang benar, tool yang tidak boleh dipanggil, serta expected final outcome.
Google Agents CLI menyediakan evaluation dataset untuk menguji apakah agent berperilaku sesuai ekspektasi. Microsoft Agent Framework juga menempatkan evaluation sebagai bagian dari operational capability agent.
Ukur metrik seperti correct tool rate, parameter accuracy, unnecessary tool calls, retry rate, dan task completion rate.
Masukkan kegagalan production ke regression dataset sehingga bug yang pernah terjadi tidak muncul kembali diam-diam setelah perubahan model.
9. Batasi Jumlah Tool Calls dan Biaya Workflow
Agent dapat masuk ke loop.
Ia memanggil tool A, mendapatkan hasil kurang jelas, mencoba tool B, kembali ke A, lalu terus mencari tanpa benar-benar mendekati penyelesaian.
Berikan execution budget.
Batasnya bisa berupa jumlah pemanggilan tool, total runtime, biaya model, jumlah retry, atau kombinasi semuanya.
OpenAI Responses API menyediakan kontrol terhadap tool yang dapat dipilih serta batas pemanggilan pada kategori tool tertentu.
Di aplikasi sendiri, tim dapat menerapkan kontrol yang lebih spesifik.
Misalnya maksimal 10 tool calls per task. Jika belum selesai, agent harus meminta input tambahan atau menyerahkan kasus kepada manusia.
Budget seperti ini mencegah satu permintaan bermasalah mengonsumsi resource secara tidak proporsinal.
10. Ukur Reliability dari Outcome Bisnis
Tool success rate 99% belum tentu berarti agent berhasil.
Bayangkan semua API call sukses, tetapi agent sering memilih tool yang salah. Secara teknis infrastructure sehat, namun outcome bisnis tetap buruk.
Karena itu, gabungkan technical metrics dan business metrics.
Pantau API error rate, latency, retry, serta availability. Lalu hubungkan dengan task success, human intervention rate, customer satisfaction, cost per completed task, dan critical error rate.
Pendekatan tersebut membuat tim mengetahui apakah tool calling benar-benar meningkatkan otomatisasi atau hanya menambah kompleksitas baru.
Reliability pada akhirnya bukan “API selalu merespons”. Reliability berarti agent dapat mencapai tujuan yang benar dengan tindakan yang aman dan dapat diprediksi.
Menggunakan Tool Calling di production membutuhkan idempotency, error classification, permission, sandbox, approval, tracing, dan evaluasi end-to-end.
Jangan hanya mengukur apakah fungsi berhasil dipanggil; ukur apakah agent memilih tool yang benar dan menghasilkan outcome bisnis yang tepat.
Mulailah membuat test suite untuk setiap tool penting, lalu gunakan kasus gagal production sebagai bahan regression testing berikutnya.