Cara AI Agent Menggunakan Tool (Penjelasan Function Calling)

Sebuah AI agent menggunakan tool lewat function calling: model membaca tugas di hadapannya, mencocokkannya dengan tool yang diberikan, lalu mengeluarkan permintaan terstruktur yang menyebut nama tool dan nilai persis yang harus diteruskan. Aplikasi Anda, atau penyedia AI itu sendiri untuk tool yang dihosting, menjalankan permintaan tersebut pada sistem nyata dan mengembalikan hasilnya, yang dibaca model sebelum memutuskan langkah berikutnya. Function calling adalah mekanisme yang mengubah model bahasa dari sesuatu yang hanya menulis teks menjadi sesuatu yang dapat memeriksa kalender, memperbarui catatan CRM, atau memproses pengembalian dana.

Ini bukan lagi fitur khusus. Gartner memprediksi bahwa 40% aplikasi enterprise akan menampilkan AI agent khusus tugas pada akhir 2026, naik dari kurang dari 5% pada 2025, dan hampir setiap agent itu bergantung pada function calling untuk melakukan apa pun selain menghasilkan balasan. Jika Anda membangun atau membeli agent, memahami cara kerja pemanggilan tool yang sebenarnya, dan di mana ia gagal, menjadi pembeda antara agent yang benar-benar berguna dan agent yang tampak mengesankan di demo lalu berantakan di produksi.

Dari Membicarakan Tugas ke Mengerjakannya

Model tanpa tool dapat menjelaskan apa yang seharusnya terjadi: "Saya sarankan menjadwalkan ulang ke hari Kamis dan mengirim konfirmasi." Model dengan tool dapat mewujudkannya. Ia memanggil tool kalender untuk memeriksa ketersediaan hari Kamis, memanggil tool pesan untuk mengirim konfirmasi, lalu melaporkan bahwa semuanya selesai. Itulah seluruh perbedaan antara chatbot dan agent, yang dibahas lebih dalam di cara kerja AI agent: persepsi mengisi penalaran, penalaran memilih tool, dan tool-lah yang benar-benar mengubah sesuatu di luar model.

Konsep ini punya nama dalam literatur AI: tool use, kadang disebut function calling tergantung vendornya. Untuk definisi dengan bahasa sederhana dan kerangka bisnisnya, apa itu tool use membahasnya. Artikel ini masuk satu tingkat lebih dalam dan berfokus pada hal yang penting begitu Anda benar-benar menjalankan agent: bagaimana pemanggilan tool disusun, bagaimana model memutuskan untuk melakukannya, apa yang terjadi saat gagal, dan bagaimana kumpulan tool yang terus bertambah dikelola tanpa berubah menjadi kekacauan.

Anatomi Pemanggilan Tool

Setiap tool yang dapat digunakan agent didefinisikan dengan cara dasar yang sama, apa pun penyedia AI yang Anda pakai. Definisi itu terdiri dari tiga bagian, dan model tidak pernah melihat lebih dari apa yang Anda masukkan ke ketiganya, struktur yang didokumentasikan secara konsisten di platform tool use Anthropic dan setiap penyedia besar lainnya:

Ketika model memutuskan menggunakan tool, ia tidak menjalankan kode apa pun sendiri. Ia mengeluarkan objek terstruktur yang menyebut tool dan mengisi parameternya, kira-kira "panggil check_order_status dengan order_id: 48213." Sistem Anda, atau infrastruktur hosting penyedia untuk tool seperti web search yang berjalan di sisi vendor, menjalankan pemanggilan itu pada sistem pesanan yang sebenarnya dan mengirim hasilnya kembali dalam percakapan yang sama. Model membaca hasil itu sebagai informasi baru dan melanjutkan, persis seperti yang digambarkan loop persepsi-penalaran-tindakan-observasi.

Kualitas deskripsi dan skema menentukan sebagian besar hasilnya. Tool bernama update_record tanpa deskripsi jenis catatan apa, atau kolom mana yang diterimanya, hampir tidak memberi model bahan apa pun. Tool yang bisa disalahgunakan model karena sebuah parameter bertipe longgar, misalnya kolom date teks bebas alih-alih format yang ketat, adalah tool yang suatu saat akan dipanggil dengan nilai yang tidak diduga siapa pun.

Bagaimana Model Memutuskan Apakah Perlu Memanggil Tool

Pada setiap giliran, model membuat keputusan kecil: apakah permintaan ini membutuhkan tool, atau dapat dijawab dari apa yang sudah diketahuinya? Pertanyaan tentang kebijakan pengembalian dana Anda mungkin dapat dijawab langsung jika teks kebijakan sudah ada di konteks. Pertanyaan tentang pesanan pelanggan tertentu membutuhkan tool, karena model tidak mengetahui data itu dan tidak akan pernah tahu kecuali ia mencarinya.

Dua hal membentuk keputusan ini. Pertama, seberapa baik deskripsi tool cocok dengan permintaan; deskripsi yang samar akan dilewati atau salah diterapkan. Kedua, bagaimana system prompt atau konfigurasi agent mengarahkan perilakunya. Agent dapat diinstruksikan untuk selalu memeriksa knowledge base sebelum menjawab, hanya memakai tool bila benar-benar diperlukan, atau mewajibkan pemanggilan tool sebelum menjawab sama sekali dalam skenario tertentu. Ini adalah pengaturan yang dapat disetel di sebagian besar framework agent, bukan perilaku tetap, itulah sebabnya dua agent yang dibangun di atas model dasar yang sama dapat bertindak sangat berbeda tergantung seberapa langsung mereka diinstruksikan untuk menggunakan tool.

Titik keputusan ini persis merupakan bagian "reason" dari loop agent. Cara kerja AI agent membahas siklus lengkap itu lebih mendalam; momen pemilihan tool yang dijelaskan di sini adalah tempat penalaran berubah menjadi tindakan. Untuk melihat lebih dekat apa yang terjadi di sisi penalaran sebelum tool dipanggil, lihat cara AI agent bernalar.

Pemanggilan Tunggal, Berurutan, Paralel, dan Bersyarat

Tidak semua tugas hanya membutuhkan satu pemanggilan tool. Pekerjaan agent yang nyata biasanya jatuh ke dalam empat bentuk:

Blueprint AI Meeting Scheduler Agent adalah contoh berurutan yang jelas: pencarian ketersediaan, lalu pemesanan, lalu konfirmasi, setiap langkah bergantung pada langkah sebelumnya. Blueprint AI Research Agent bertumpu pada pemanggilan paralel dan berurutan sekaligus, menanyai beberapa sumber sekaligus lalu membaca setiap hasil untuk memutuskan pencarian berikutnya. Blueprint AI Support Triage Agent adalah kasus bersyarat: klasifikasi menentukan apakah pemanggilan tool berikutnya berupa pencarian knowledge base, tindakan routing, atau eskalasi.

Seperti Apa Tool dalam Blueprint Produksi

Deskripsi abstrak hanya sejauh itu. Berikut tampilan kumpulan tool pada pekerjaan nyata.

AI SDR Agent memanggil tool riset untuk menarik data firmografik akun target, tool CRM untuk memeriksa hubungan yang sudah ada dan mencatat outreach, dan tool email untuk mengirim sekuens. Tiga tool, tiga sistem berbeda, satu pekerjaan yang koheren.

AI Invoice AP Agent memanggil tool ekstraksi dokumen untuk menarik item baris dari faktur, tool pencarian vendor untuk mencocokkannya dengan purchase order, dan tool ERP untuk memposting pembayaran yang disetujui. Setiap pemanggilan tool di sini memiliki konsekuensi finansial nyata, itulah sebabnya ada langkah persetujuan di antara ekstraksi dan posting, bukan membiarkan agent merangkai semuanya langsung.

Perhatikan polanya: tool yang dapat diakses agent menentukan batas atas dari apa yang dapat dilakukannya, tidak lebih. Agent dengan tool CRM hanya-baca dapat mencari catatan tetapi tidak dapat mengubahnya. Agent dengan tool yang dapat menulis bisa. Batas itu adalah keputusan desain, bukan kebetulan, dan biasanya hal pertama yang layak ditinjau ketika agent melakukan sesuatu yang tidak Anda duga.

Ketika Pemanggilan Tool Gagal: Error, Retry, dan Batas

Pemanggilan tool lebih sering gagal daripada yang ditunjukkan demo. Mode kegagalan yang umum:

• Parameter salah atau hilang. Model menebak nilai yang tidak diberikan kepadanya, terutama pada permintaan yang ambigu. Agent yang dibangun dengan baik mengajukan pertanyaan klarifikasi alih-alih menebak untuk hal yang berdampak.
• Error izin. Tool-nya ada, tetapi kredensial agent tidak mengizinkan tindakan spesifik itu, pengaman yang seharusnya tetap dipertahankan, bukan "diperbaiki" dengan melebarkan akses.
• Tool tidak ada atau salah diingat. Lebih umum terjadi pada kumpulan tool yang besar dan tidak tertata daripada pada kumpulan yang kecil dan terbatas cakupannya.
• Timeout dan gangguan. Sistem hilir lambat atau mati, dan agent membutuhkan fallback yang terdefinisi, bukan menggantung atau menebak hasil.

Skala mengubah masalah ini. Panduan function calling dari OpenAI sendiri merekomendasikan agar jumlah tool yang tersedia dalam satu giliran tetap kecil, umumnya di bawah 20, karena akurasi menurun saat model harus membedakan semakin banyak opsi yang tampak mirip. Untuk agent yang benar-benar membutuhkan pustaka tool besar, solusinya bukan menjejalkan semuanya ke setiap prompt, melainkan memuat hanya subset yang relevan untuk tugas yang sedang dikerjakan, sehingga model memilih dari daftar yang singkat dan relevan, bukan yang membanjiri.

Langkah observasi-lah yang menangkap sebagian besar masalah ini. Agent yang dirancang dengan baik memeriksa apakah pemanggilan tool benar-benar berhasil sebelum menganggapnya selesai, melakukan retry saat kegagalan bersifat sementara, dan menyerahkan kepada manusia alih-alih menebak saat kegagalan berulang. Agent yang menembakkan pemanggilan tool dan berasumsi berhasil adalah akar masalah paling umum di balik "AI-nya bilang sudah mengirim email tetapi ternyata tidak."

Function Calling dan Masalah Standardisasi

Untuk beberapa waktu, setiap integrasi tool adalah pekerjaan khusus: konektor buatan sendiri untuk CRM Anda, satu lagi untuk kalender, satu lagi untuk help desk, masing-masing rusak dengan cara sedikit berbeda ketika API-nya berubah atau Anda berganti penyedia AI. Model Context Protocol mengatasi ini dengan menstandardisasi cara model menemukan dan memanggil tool, sehingga tool yang dibuat sekali dapat bekerja di berbagai penyedia AI tanpa dibangun ulang untuk masing-masing.

Standar ini tumbuh cepat. Anthropic, yang awalnya mengembangkan MCP, melaporkan lebih dari 10.000 server MCP publik aktif per Desember 2025, naik dari beberapa ratus saat peluncuran setahun sebelumnya, dan protokol ini kini berada di bawah sebagian besar platform agentic utama, bukan di sampingnya. Jika Anda menghubungkan agent ke kumpulan alat bisnis yang terus bertambah tanpa membangun ulang lapisan integrasi setiap kali berganti model, apa itu Model Context Protocol adalah rujukan yang lebih mendalam, termasuk pertimbangan keamanan yang menyertai penghubungan himpunan server yang lebih luas.

Guardrail: Apa yang Tidak Boleh Dilakukan Tool Secara Bebas

Tidak semua pemanggilan tool layak mendapat kepercayaan yang sama. Pencarian hanya-baca dan tindakan penerbitan pengembalian dana membawa risiko yang sangat berbeda jika agent salah, dan memperlakukan keduanya sama adalah cara kesalahan penalaran kecil berubah menjadi kerugian finansial atau pelanggan yang nyata.

Pola yang berhasil: batasi setiap tool pada izin tersempit yang masih menyelesaikan pekerjaan, wajibkan langkah persetujuan manusia untuk tool yang bersifat finansial, tidak dapat dibatalkan, atau menghadap pelanggan dalam skala besar, dan catat setiap pemanggilan sehingga tindakan yang salah dapat dilacak setelahnya, bukan menjadi misteri. Ini adalah disiplin yang sama yang dibahas di guardrails AI agent, dan inilah yang membedakan agent yang aman dibiarkan berjalan dari agent yang secara teknis bekerja sampai hari ketika ia tidak lagi bekerja. Pola Autonomous Agent membahas lebih jauh mengapa loop pemanggilan tool adalah bagian paling berisiko dari desain agent mana pun, karena setiap pemanggilan adalah peluang untuk mengubah keadaan nyata.

Key Facts

• Function calling bekerja melalui tiga bagian: nama tool, deskripsi dalam bahasa biasa, dan skema parameter. Model tidak pernah mengeksekusi kode sendiri; ia mengeluarkan permintaan terstruktur yang dijalankan sistem Anda.
• Model memutuskan apakah akan memanggil tool dengan mencocokkan permintaan dengan deskripsi tool dan mengikuti instruksi yang diberikan tentang kapan menggunakan tool dibanding langsung menjawab.
• Pemanggilan tool terjadi dalam empat bentuk: tunggal, berurutan, paralel, dan bersyarat, sering kali digabungkan dalam satu proses agent.
• Akurasi menurun seiring bertambahnya jumlah tool yang tersedia. OpenAI merekomendasikan menjaga daftar tool aktif di bawah sekitar 20 dan memuat tool tambahan sesuai kebutuhan untuk pustaka yang lebih besar.
• Model Context Protocol menstandardisasi integrasi tool di berbagai penyedia AI, dan ekosistemnya telah tumbuh melampaui 10.000 server publik aktif.

Langkah Selanjutnya

Tool use adalah yang memberi agent tangan. Padukan dengan sisi penalaran dari loop di cara AI agent bernalar untuk melihat bagaimana model memutuskan tool mana yang dipilih dan kapan berhenti, dan lihat cara kerja AI agent untuk loop lengkap tempat pemanggilan tool ini berada. Jika Anda membandingkan platform untuk membangun, ulasan alat otomatisasi dan panduan alat otomatisasi no-code terbaik membahas di mana kemampuan pemanggilan tool muncul pada produk yang dapat Anda beli saat ini.