Agentic Resource Discovery: katalog ai-catalog.json, verifikasi, dan batas otorisasi phone agent

Masalah yang diselesaikan Agentic Resource Discovery

Agentic Resource Discovery, atau ARD, menjawab pertanyaan sederhana yang makin penting: bagaimana agen AI menemukan alat, skill, dan agen lain yang benar-benar diterbitkan oleh sumber yang dapat diperiksa? Dalam pengumuman Google Developers pada 17 Juni 2026, ARD diperkenalkan sebagai spesifikasi terbuka untuk menerbitkan, menemukan, dan memverifikasi sumber daya agen di web. Intinya bukan membuat agen langsung menjalankan apa pun, melainkan memberi cara standar agar kapabilitas dapat diumumkan dan ditemukan tanpa daftar privat yang terpecah-pecah.

Komponen yang sering dicari pembaca adalah ai-catalog.json. Dalam pola ARD, katalog seperti ini dapat di-host di domain penerbit dan berisi metadata tentang kapabilitas yang tersedia: jenis sumber daya, deskripsi, endpoint, protokol yang dipakai, dan informasi kepercayaan yang membantu klien memutuskan apakah sumber itu layak diperiksa lebih lanjut. Bagi tim produk, ini mirip direktori kemampuan yang bisa dibaca mesin, tetapi tetap harus diperlakukan sebagai metadata, bukan izin.

Perbedaan itu penting untuk phone agent. Menemukan bahwa sebuah layanan mengiklankan tool kalender, lokasi, atau pesan tidak sama dengan memberi wewenang untuk membuka aplikasi di ponsel pengguna. ARD membantu tahap “apa yang tersedia dan dari siapa”, sedangkan runtime ponsel masih harus menentukan “apakah alat ini diaktifkan, apakah pengguna memberi izin, apakah targetnya benar, dan apakah tindakan ini boleh dilanjutkan”.

Cara katalog dan registri menerbitkan kapabilitas

Alur ARD dapat dibaca sebagai empat tahap: publish, discover atau resolve, verify, lalu connect. Pada tahap publish, sebuah organisasi menerbitkan katalog di domainnya sendiri. Katalog itu dapat menjelaskan MCP server, A2A agent, OpenAPI tool, atau katalog turunan. Dengan cara ini, penerbit tidak perlu menunggu satu marketplace pusat untuk menjelaskan kemampuan yang ingin dibuat dapat ditemukan oleh agen.

Pada tahap discover, klien punya dua jalur. Jika sudah tahu domain mitra, klien dapat mengambil katalog langsung dari domain tersebut. Jika belum tahu sumbernya, klien dapat bertanya ke registri dengan niat, misalnya “temukan tool pemrosesan invoice” atau “temukan agen pemesanan layanan”. Registri kemudian mengembalikan kandidat kapabilitas beserta metadata yang membantu proses penilaian. Repositori publik spesifikasi ARD menunjukkan bahwa spesifikasi, skema, arsitektur kepercayaan, dan pekerjaan referensi berkembang secara terbuka.

Peran katalog dan registri berbeda. Katalog adalah pernyataan penerbit tentang kapabilitasnya. Registri adalah indeks yang membantu pencarian lintas domain. Keduanya belum menjadi broker eksekusi. Setelah kandidat ditemukan, klien masih harus memeriksa sumber, kompatibilitas endpoint, protokol, kebijakan lokal, dan batas pengguna sebelum membuat koneksi nyata.

Apa yang dibuktikan verifikasi penerbit

Verifikasi penerbit membuat ARD lebih berguna daripada sekadar daftar URL. Dalam produksi, pengumuman ARD menyebutkan kemungkinan metadata penerbit yang dapat diverifikasi secara kriptografis sebelum klien membuat koneksi langsung melalui protokol asli. Bagi pengguna dan developer, manfaatnya jelas: agen dapat mengurangi risiko tersambung ke katalog tiruan atau endpoint yang mengaku sebagai layanan tertentu.

Namun verifikasi identitas tidak sama dengan jaminan perilaku. Jika katalog benar-benar berasal dari penerbit yang dimaksud, kita baru tahu asalnya lebih jelas. Kita belum tahu apakah kapabilitas itu cocok untuk tugas pengguna, apakah endpoint stabil, apakah izin yang diminta masuk akal, apakah tindakan memiliki konsekuensi eksternal, atau apakah runtime lokal mengizinkan tool itu. Katalog alat agen tepercaya harus dibaca sebagai awal evaluasi, bukan akhir keputusan.

Risiko yang tersisa biasanya muncul setelah identitas berhasil: metadata bisa usang, deskripsi bisa terlalu umum, endpoint bisa berubah, scope bisa lebih luas dari kebutuhan, atau hasil tool bisa memicu tindakan lanjutan yang sensitif. Untuk phone agent, risiko itu bertemu data pribadi dan kontrol perangkat. Karena itu, verifikasi penerbit harus digabungkan dengan kebijakan runtime, persetujuan pengguna, catatan aktivitas, dan jalur revokasi.

Bagaimana ARD meneruskan koneksi ke MCP, A2A, OpenAPI, dan kontrak aplikasi

ARD tidak menggantikan MCP, A2A, OpenAPI, atau kontrak aplikasi. Ia membantu klien menemukan metadata dan memilih endpoint yang diiklankan, lalu koneksi nyata tetap memakai antarmuka asli yang disediakan kapabilitas tersebut. Jika katalog mengiklankan MCP server, klien masih perlu berbicara MCP. Jika entri menunjuk OpenAPI, klien tetap harus membaca kontrak API, skema input, autentikasi, dan responsnya.

Pemisahan ini menjaga tanggung jawab tetap jelas. ARD menjawab “di mana dan apa yang tersedia”. Protokol asli menjawab “bagaimana memanggilnya”. Runtime lokal menjawab “apakah panggilan itu diizinkan di konteks pengguna ini”. Pada ponsel, masih ada satu pertanyaan tambahan: apakah tindakan yang dihasilkan punya jalur Android yang didukung dan dapat diperiksa pengguna?

Untuk aplikasi mobile, discovery hanya bernilai jika ada kontrak tindakan yang benar-benar bisa dipanggil. Tidak semua aplikasi Android membuka aksi yang dapat dipanggil mesin, dan tidak semua aksi aman dijalankan tanpa langkah konfirmasi. Pembahasan khusus tentang kontrak aplikasi setelah tahap discovery ada di App Intents dan Aplikasi yang Dapat Dipanggil Mesin untuk AI Agent, karena halaman ini fokus pada perbedaan antara menemukan sumber daya dan memberi otoritas ponsel.

Mengapa penemuan bukan otorisasi di ponsel

Ponsel bukan sekadar endpoint komputasi. Di dalamnya ada kontak, pesan, lokasi, kamera, file, akun kerja, notifikasi, dompet, dan aplikasi yang membawa konsekuensi nyata. Karena itu, katalog alat ai-catalog.json yang valid hanya memberi tahu bahwa sebuah kapabilitas tersedia dari sumber tertentu. Ia tidak mengaktifkan tool di runtime pengguna, tidak memberi izin Android, tidak memilih target tindakan, dan tidak menyetujui konsekuensi seperti mengirim pesan atau mengubah pengaturan.

Android sendiri memperlakukan izin sebagai tanggung jawab aplikasi. Panduan runtime permission Android menekankan permintaan izin dalam konteks saat fitur membutuhkannya, termasuk penanganan saat izin ditolak. Itu adalah lapisan yang berbeda dari verifikasi penerbit ARD. Domain yang benar tidak membuat izin lokasi otomatis sah; izin lokasi juga tidak membuktikan bahwa tindakan bisnis yang diminta pengguna sudah tepat.

Untuk desain skill dan izin yang lebih dalam, pembaca dapat melanjutkan ke Keamanan Skill AI Agent: Mengapa Phone Agent Perlu Cek Izin Saat Berjalan. Jika kebutuhan Anda adalah mengaitkan identitas, wewenang, dan catatan aktivitas dalam satu alur tata kelola, Identitas, izin, dan audit trail AI agent: lapisan keamanan untuk agen ponsel membahas lapisan tersebut tanpa mengulang detail ARD.

Checklist sebelum menghubungkan dan menjalankan sumber daya

Checklist phone agent harus dimulai sebelum koneksi dibuat. Pertama, cocokkan niat pengguna dengan entri katalog: apakah deskripsinya benar-benar relevan, atau hanya mirip secara kata kunci? Kedua, periksa penerbit dan kesegaran katalog. Katalog yang lama, tidak lengkap, atau tidak punya metadata kepercayaan yang memadai sebaiknya masuk jalur evaluasi lebih ketat.

1. Verifikasi penerbit, domain, dan metadata katalog sebelum memilih endpoint.
2. Pastikan protokol asli didukung: MCP, A2A, OpenAPI, atau kontrak aplikasi lain yang benar-benar bisa dipanggil runtime.
3. Uji scope dengan tugas rendah risiko, bukan langsung dengan tindakan yang mengirim, menghapus, membeli, atau mengubah pengaturan.
4. Periksa apakah tool harus diaktifkan secara lokal dan apakah kebijakan runtime mengizinkan kategori risikonya.
5. Validasi target tindakan: kontak, aplikasi, file, lokasi, akun, atau objek kerja harus jelas.
6. Minta persetujuan berbasis risiko saat tindakan punya efek eksternal, membaca data sensitif, atau mengubah perangkat.
7. Tampilkan hasil yang bisa diperiksa, simpan catatan aktivitas yang berguna, dan siapkan stop serta revokasi.
8. Jika endpoint gagal, jangan diam-diam berpindah ke sumber lain dengan otoritas berbeda; minta klarifikasi atau turunkan risiko tugas.

Urutan ini menjaga discovery tetap berguna tanpa membuatnya terlalu berkuasa. Agen boleh lebih cepat menemukan sumber daya, tetapi keputusan eksekusi tetap harus dapat diamati. Dalam tugas ponsel, kegagalan yang baik lebih berharga daripada keberhasilan yang tidak bisa dijelaskan, karena pengguna perlu tahu apakah tindakan berhenti, tertunda, membutuhkan izin, atau menunggu konfirmasi.

Cara FoneClaw memisahkan visibilitas katalog dari wewenang ponsel

Di FoneClaw, kami memandang katalog sebagai cara membuat kemampuan terlihat, bukan sebagai pintu otomatis menuju tindakan. FoneClaw adalah runtime Android phone agent: model kompatibel yang dikonfigurasi membantu memahami tujuan, menalar, dan menyusun rencana; FoneClaw memanggil tool Android yang didukung dan diatur oleh kebijakan runtime. Pembagian ini menjaga kecerdasan model tetap berada di dalam alur yang dapat diperiksa pengguna.

Berdasarkan data rilis FoneClaw yang tersedia pada 1 Agustus 2026, versi 0.1.0 menambahkan manajemen per-tool, kontrak yang lebih aman, pemulihan izin, dan kelanjutan plugin tepercaya. Jalur plugin yang ditandatangani dan dikirim melalui paket tepercaya kami perlakukan sebagai alur terlihat, bukan instalasi diam-diam. Sementara itu, katalog tool publik FoneClaw pada tanggal yang sama berisi 118 built-in tools dalam 11 kategori dengan label risiko dan approval. Dalam copy yang lebih tahan waktu, kami menyebutnya 100+ built-in tools karena katalog produk dapat berkembang.

Artinya, jika sebuah model merencanakan tindakan seperti membaca layar, membuka aplikasi, menyiapkan pesan, mengambil lokasi, atau menjalankan workflow, rencana itu masuk ke tool yang sudah diatur, bukan langsung menjadi sentuhan ponsel bebas. Izin dipandu saat dibutuhkan, hasil dibuat terlihat, dan tindakan berisiko mengikuti kebijakan approval yang sesuai. Untuk gambaran penuh tentang bagaimana niat berubah menjadi tindakan Android yang didukung, rujukan paling tepat adalah Kontrol Ponsel dengan AI Agent: Cara Kerja, Batas, dan Keamanan Android.

Kami tidak menempatkan FoneClaw sebagai implementasi ARD dalam artikel ini. Yang kami gunakan adalah prinsip yang sama-sama penting: sumber daya boleh ditemukan, tetapi otoritas ponsel harus tetap lokal, eksplisit, dan dapat dicabut. Dengan begitu, katalog membantu navigasi kemampuan, sementara runtime tetap menjaga batas tindakan.

Apa yang perlu diuji sebelum memakai registri sumber daya agen

Sebelum tim mengadopsi registri sumber daya agen, ukur kualitas discovery dengan skenario nyata. Berapa banyak hasil yang relevan? Berapa banyak false match yang tampak benar tetapi gagal saat kontrak dipanggil? Apakah katalog usang terdeteksi? Apakah verifikasi gagal dengan cara yang jelas? Apakah registri menjelaskan alasan sebuah kandidat dipilih, atau hanya mengembalikan daftar yang terlihat meyakinkan?

Uji berikutnya adalah pemisahan kebijakan. Saat katalog menawarkan tool dengan scope luas, runtime harus dapat menolak, membatasi, atau meminta persetujuan tambahan. Saat endpoint berubah, sistem harus bisa menghentikan koneksi sampai kontrak divalidasi ulang. Saat pengguna mencabut izin Android, agen harus memperbarui status tugas, bukan mencoba jalur tersembunyi.

Untuk phone agent, indikator kesiapan terbaik adalah observabilitas dari awal sampai akhir: query discovery, katalog yang dipilih, hasil verifikasi, endpoint yang dipakai, tool lokal yang diaktifkan, izin yang diminta, target tindakan, persetujuan, hasil, log, dan revokasi. Jika salah satu tahap tidak bisa diperiksa, jangan memperlakukannya sebagai siap produksi untuk tindakan ponsel. ARD membuat penemuan lebih standar; keamanan tindakan tetap ditentukan oleh runtime, kebijakan, dan pengalaman konfirmasi yang benar.