Agen Anda tidak butuh setiap tool di dalam konteksnya

Agen AI DynoTable bisa menjangkau 38 tool. Jarang sekali ia melihat semuanya sekaligus. Di mana kami menarik garis antara apa yang langsung didapat model dan apa yang harus ia cari sendiri ternyata menjadi keputusan paling berpengaruh di seluruh toolkit — dan garis itu berakhir jauh dari tempat kami menaruhnya pertama kali.

Kami membangun mekanisme penemuan agar model memulai dengan himpunan kecil lalu mencari sisanya. Lalu kami mengamati model-model murah memakainya, dan memindahkan 27 dari 38 tool itu kembali ke inti yang selalu terlihat. Mekanismenya bertahan. Teori kami tentang siapa yang membutuhkannya tidak.

Inilah yang kami pelajari saat membangun permukaan tool untuk model-model yang tak bisa diandalkan untuk mencari sendiri.

Tool yang tak pernah dipanggil model tetap memakan biaya

Setiap tool yang Anda paparkan adalah nama, deskripsi, dan schema input lengkapnya, diserialisasi ke dalam request sebelum pengguna mengetik apa pun. Tiga puluh delapan hal semacam itu tidak gratis.

Token adalah bagian yang lebih kecil dari tagihan. Biaya sebenarnya adalah akurasi pemilihan: makin banyak opsi nyaris-identik yang dipindai model, makin sering ia memilih yang salah. Katalog kami penuh opsi nyaris-identik dengan sengaja. Lima tool kami ada dua kali — openTable dan proposeOpenTable, openWorkbench dan proposeOpenWorkbench, dan seterusnya. Tiap pasangan melakukan hal yang sama; yang satu melakukannya seketika, yang lain memunculkan chip yang harus diklik pengguna lebih dulu. Pembedaan itu menopang keamanan agen dan nyaris tak terlihat dalam daftar nama yang datar.

Panduan klien Model Context Protocol sendiri membuka dengan poin persis ini: memuat setiap definisi tool di awal memboroskan token, menambah latensi, dan menurunkan performa model. Menyetujuinya mudah. Menentukan tool mana yang kehilangan kursinya — di situlah menariknya.

Kami membangun tool pencarian. Model batas bawah tak mau memanggilnya.

Mekanismenya dua tingkat. Sehimpunan tool aktif sejak langkah pertama. Sisanya tak terlihat sampai model memanggil searchTools(query), yang menilai katalog berdasarkan nama, deskripsi, dan kata kunci, mengembalikan hasil yang cocok, lalu menambahkannya ke himpunan tool yang boleh dipanggil model pada langkah-langkah berikutnya.

Lalu kami menjalankannya terhadap model batas bawah kami. Kami tidak menyetel agen ini terhadap model frontier — ia berjalan pada kredensial Bedrock Anda sendiri, jadi orang memilih model murah, dan kami mengoptimalkan untuk yang paling murah. Ketika ditanya soal sebuah file yang dilampirkan, model itu justru berburu lewat daftar tab yang terbuka. Ia nyaris tak pernah memanggil tool pencarian sama sekali. Apa pun yang tidak langsung terlihat tidak eksis baginya.

Hasil itu mematikan rancangan yang paling gamblang. Jika penemuan adalah satu-satunya jalan menuju sebuah tool, setiap permintaan yang membutuhkan tool tersebut bergantung pada keputusan model untuk mencari — dan model yang paling mungkin butuh bantuan justru paling kecil kemungkinannya meminta.

Maka pembagiannya berhenti menjadi "inti kecil, ekor besar" dan berubah menjadi pertanyaan tentang permintaannya, bukan tentang tool-nya: apakah rumusan pengguna menyebut nama tool itu? 11 tool yang kami biarkan hanya bisa ditemukan lewat pencarian adalah yang jawabannya ya. "Ekspor ini ke CSV" membuat model mencari export. "Tunjukkan pesanan bulan lalu" tidak membuatnya mencari tool penyetel filter, jadi yang itu tetap inline. Statistik indeks, spec tersimpan, introspeksi relasi, dan permukaan perubahan yang di-stage semuanya adalah hal yang diminta pengguna dengan menyebut namanya ketika mereka menginginkannya, dan tak pernah secara implisit.

Dua puluh tujuh tool inline bukan angka yang akan kami bela sejak awal. Itu angka yang bertahan setelah bersinggungan dengan model yang benar-benar menjadi acuan pengiriman kami.

Kondisi balapan yang diam-diam akan membuat penemuan tak berguna

Penemuan punya kendala pewaktuan yang mudah dibuat salah dan sulit disadari.

Ketika tool pencarian mengembalikan hasil yang cocok, nama-nama itu harus bergabung ke himpunan yang diizinkan sebelum langkah berikutnya dari model disiapkan. Tempat paling gamblang untuk melakukannya adalah hook yang menyala saat sebuah langkah selesai. Hook itu didokumentasikan menyala, pada sebagian versi SDK, setelah penyiapan langkah berikutnya — yang artinya mutasinya mendarat terlambat satu langkah.

Mode kegagalannya jahat. Model mencari. Ia mendapat hasil yang benar yang menyebutkan tool yang ia butuhkan. Ia memanggil tool itu tepat pada langkah berikutnya dan diberi tahu bahwa tool tersebut tidak ada. Sifatnya intermiten, bergantung pada versi SDK mana yang teresolusi, dan tampaknya seperti model yang bodoh alih-alih harness yang rusak.

Perbaikannya adalah memutasi himpunan yang diizinkan di dalam eksekusi tool pencarian itu sendiri, yang dijamin selesai sebelum loop bergerak maju. Itu selisih satu baris soal di mana sebuah pernyataan berada, dan itulah pembeda antara mekanisme penemuan yang bekerja dan yang gagal pada sebagian kecil kesempatan karena alasan yang tak akan diatribusikan siapa pun dengan benar.

Tiga kali pencarian, lalu berhenti

Pencarian dibatasi 3 panggilan per giliran agen. Yang keempat mengembalikan ini alih-alih berjalan:

{"error": "search-budget-exhausted", "budgetCap": 3}

Batas itu ada karena satu loop tertentu: model mencari, tak menemukan apa yang ia bayangkan, mencari lagi dengan sinonim, tak menemukan itu juga, dan menghabiskan seluruh anggaran langkahnya di dalam tool pencarian tanpa sekali pun menyentuh database. Membatasinya memaksa sebuah keputusan — berkomitmen pada salah satu tool yang sudah ditemukan, atau bertanya kepada pengguna — tepat di titik ketika mencari lebih jauh sudah berhenti membuahkan hasil.

Pesan error ketika model memanggil tool yang belum ia temukan mengikuti prinsip yang sama dengan yang kami pakai untuk setiap validator di dalam agen:

Tool 'startExport' not in active set. Call searchTools(query='startExport')
to discover it, or use one of: <inline tool names>

Penolakan yang menyebutkan tindakan pemulihannya memakan satu langkah ekstra. Penolakan yang cuma berkata tidak memakan seluruh gilirannya.

Satu baris per tool, sisanya diturunkan

Setiap tool dideklarasikan sekali, dalam satu daftar datar, dan barisnya membawa seluruh identitas tool tersebut: nama dan deskripsinya, kata kunci yang dicocokkan pencarian, apakah ia dimulai inline atau harus ditemukan lebih dulu, tier mana tempatnya berjalan, dan bagaimana ia dipaparkan lewat MCP.

Tier-tier itu sama pentingnya dengan pembagian visibilitas. 21 tool bersifat silent — pembacaan yang berjalan tanpa mengganggu siapa pun. 16 bersifat gated di balik tangga otorisasi. Tepat satu tak masuk keduanya, karena tool pencarian bukanlah kapabilitas yang dipakai agen atas data Anda; ia bagian dari loop itu sendiri. Paparan MCP adalah sumbu ketiga pada baris yang sama: read-only, staging, penuh, atau dikecualikan sama sekali — yang berlaku untuk 3 tool.

Aturan yang menjaga ini tetap jujur adalah bahwa setiap daftar lain di dalam sistem diturunkan dari baris-baris itu — himpunan tier silent, tier scope MCP, himpunan write-scoped — dan tak satu pun dipelihara manual. Daftar silent yang dipelihara tangan berdampingan dengan daftar MCP yang dipelihara tangan adalah persis cara sebuah tool berakhir ter-gate dengan benar di chat dan diam-diam tak ter-gate bagi klien eksternal.

Kendala yang tak kami perkirakan adalah bahwa daftar deklarasi itu harus mengandung nol import runtime. Ia dipakai bersama oleh UI desktop dan backend, dan satu import saja menjangkau, secara transitif, sebuah dependensi crypto khusus-Node lewat implementasi salah satu tool. Tarik itu ke dalam bundle browser dan aplikasinya gagal saat modul dimuat. Baik type checker maupun unit test tak menangkapnya — keduanya meresolusi import itu dengan senang hati. Yang menangkapnya adalah sebuah tes yang membaca file tersebut sebagai teks dan gagal pada pernyataan import apa pun, yang terasa kasar sampai pertama kalinya ia menyelamatkan Anda.

Apa yang bisa dipindahkan jika Anda sedang membangunnya

• Hitung tool Anda sebelum membela arsitektur Anda. Pembagian yang tepat adalah hasil pengukuran, bukan prinsip.
• Uji penemuan terhadap model terlemah Anda. Model frontier akan mencari ketika seharusnya mencari; itu tak memberi tahu apa pun tentang model yang dipilih pengguna Anda.
• Tentukan visibilitas berdasarkan apakah rumusan pengguna sendiri menyebut nama tool-nya. Tool yang dipanggil secara implisit tempatnya inline; tool yang diminta orang dengan menyebut namanya boleh dibiarkan untuk ditemukan.
• Periksa kapan hook langkah di framework Anda benar-benar menyala sebelum Anda menaruh apa pun yang sensitif terhadap urutan di dalamnya.
• Batasi meta-tool. Apa pun yang bisa dipanggil berulang tanpa menyentuh state nyata pasti akan dipanggil begitu, dan anggaran langkah yang habis untuk mencari adalah giliran yang terbuang.
• Buat error tool-yang-belum-ditemukan menyebutkan panggilan pemulihannya, sama seperti error validator lainnya.
• Deklarasikan setiap tool sekali dan turunkan setiap daftar lain darinya. Dua daftar tool yang sama yang dipelihara tangan pada akhirnya akan berselisih, dan perselisihannya muncul di batas keamanan.
• Jika sebuah modul membawa kendala penopang yang tak bisa diungkapkan compiler Anda, tulislah tes kasar yang menegakkannya sebagai teks.

Di mana ini berjalan

Semua ini dikirimkan di dalam katalog tool milik DynoTable — query yang sadar-schema pada kredensial AWS Bedrock Anda sendiri, dengan penulisan yang selalu hanya mendarat di area staging yang bisa ditinjau. Deklarasi yang sama menggerakkan server MCP tempat agen eksternal terhubung, di mana tier paparan pada setiap baris menjadi scope yang diberikan kepada klien eksternal; bagaimana kami membuatnya aman — OAuth, consent, isolasi kredensial — adalah cerita tersendiri.

Dan lapisan di bawah semuanya itu, yaitu validator yang membuat setiap tool ini bisa dilalui model murah, adalah postingan tersendiri.