AWS Agent Registry Rilis: Solusi Cari Tools AI Otomatis Saat Runtime

Masalah Hardcoded Tools di Sistem Skala Besar

Kenapa sih pendekatan lama mulai ditinggalkan waktu sistem agen makin gede? Di lingkungan enterprise, ada puluhan sampai ratusan layanan internal yang dibuka buat AI. Kalau pendekatan kaku tetap dipakai, ada beberapa masalah utama yang langsung muncul:

1. Konteks Token Bengkak: Ratusan skema JSON fungsi dijejalkan ke model sebelum user mengetik apa pun. Biaya token API meroket padahal user cuma nanya hal sepele.
2. Halusinasi Nama Tool: Model gampang bingung membedakan puluhan tool dengan parameter yang mirip-mirip.
3. Rilis yang Ribet: Tiap ada divisi yang nambah satu API baru, tim orkestrator pusat harus memperbarui kode, ngetes ulang, dan deploy ulang sistem.

Lewat aws agent registry, agen orkestrator nggak perlu tahu daftar semua tools dari awal. Agen bakal mencari tool yang pas via natural language search hanya ketika ada pertanyaan masuk.

Cara Kerja Alur Discover, Instantiate, dan Execute

Pola kerja yang dipakai dalam implementasi AWS Agent Registry mengandalkan siklus tiga langkah sederhana: cari, buat, dan jalankan.

Berikut rincian dari tiap tahapannya:

1. Discover (Pencarian): Orkestrator mengirimkan pertanyaan user dalam bentuk pencarian semantik ke data plane AWS Agent Registry. Registry bakal membalas dengan identitas record, nama, deskripsi, tipe record, versi, serta deskriptor protokol (seperti metadata MCP server atau A2A agent card). Penting dicatat, hasil pencarian tidak pernah mengembalikan kredensial login atau token otentikasi.
2. Instantiate (Pembuatan Klien): Berdasarkan metadata protokol yang diterima, orkestrator membentuk klien secara langsung. Misalnya, jika deskriptor menunjuk ke Amazon Bedrock AgentCore Gateway, orkestrator mengambil token Cognito OAuth dari jalur terpisah yang aman dan memasukkannya ke MCPClient. Untuk agent-to-agent (A2A), wrapper memanggil AgentCore runtime lewat Boto3 yang ditandatangani izin IAM.
3. Execute (Eksekusi Agen Singkat): Sistem membentuk agen bagian dalam (inner agent) yang bersifat sementara (ephemeral), khusus berisi tools yang baru saja ditemukan. Model bahasa seperti Anthropic Claude Sonnet di Amazon Bedrock mengeksekusi fungsi yang dibutuhkan dan merangkum hasilnya ke user. Setelah giliran obrolan beres, agen sementara dan kliennya langsung dimusnahkan. Permintaan berikutnya bakal memulai pencarian baru dari nol.

Arsitektur Multi Agent Bedrock dan MCP Server Orchestration

Untuk menyusun arsitektur multi agent bedrock yang solid, implementasi referensi AWS menggabungkan beberapa komponen cloud utama. Kolaborasi ini memastikan mcp server orchestration berjalan mulus dan aman.

Implementasi Kode Python: Dari Kontrol Sampai Eksekusi

Berdasarkan kode sampel repositori AWS, proses registrasi diawali dengan membuat registry menggunakan kontrol plane. Di sini tim bisa menentukan apakah tools butuh persetujuan manual atau otomatis.

registry_client = session.client("agent-registry-control")
dp_client = session.client("agent-registry")

# Bikin Registry baru dengan konfigurasi manual approval
reg = registry_client.create_registry(
    name="OrderManagementRegistry",
    description=(
        "Registry for Order Management & Customer Service — "
        "agent discovers tools and agents via semantic search"
    ),
    approvalConfiguration={"autoApprovalRules": []},
)
REGISTRY_ARN = reg["registryArn"]

Setiap tools atau agent yang didaftarkan wajib memiliki recordType yang jelas, yaitu MCP untuk server Model Context Protocol atau AGENT untuk agent-to-agent. Deskriptor protokol disimpan dalam format JSON terstruktur yang memuat skema tools atau kartu agent.

Untuk alur persetujuan, sistem memakai status bertahap. Tool yang baru diunggah bakal berstatus DRAFT, lalu diajukan ke PENDING_APPROVAL, sampai disetujui menjadi APPROVED oleh akun yang memiliki izin IAM terpisah.

# Mengubah status record dari DRAFT menuju APPROVED
if record["status"] == "DRAFT":
    registry_client.submit_registry_record_for_approval(
        registryId=REGISTRY_ID,
        recordId=record_id,
    )
    registry_client.update_registry_record_status(
        registryId=REGISTRY_ID,
        recordId=record_id,
        status="APPROVED",
        statusReason="Approved",
    )

Saat aplikasi menerima pesan dari pengguna, orkestrator memanggil fungsi discover_and_execute. Di dalamnya, pencarian hibrida dilakukan, klien diaktifkan, dan request-scoped agent dijalankan secara dinamis.

Kamu adalah asisten Order Management & Customer Service. Gunakan tool yang tepat untuk setiap permintaan:- Pengecekan pesanan, status, pembatalan, ubah alamat: gunakan MCP tools- Harga, diskon, kode promo: gunakan tool pricing_agent- Retur, refund, komplain, eskalasi: gunakan customer_support_agentSelalu pilih tool yang paling spesifik untuk menyelesaikan tugas pengguna.

Setelah tugas selesai dieksekusi, semua koneksi MCP langsung dihentikan (client.stop()) agar resource komputasi tidak menggantung sia-sia.

Untuk memantau kualitas jalannya agen di sistem nyata, baca panduan teknis kami tentang /developer/evaluasi-ai-agent-amazon-bedrock-agentcore biar kamu paham metrik evaluasi yang tepat.

3 Skenario Uji Coba: Bukti Kehebatan Semantic Search

Dalam pengujian sampel resmi AWS, alur runtime discovery diuji dengan tiga skenario dunia nyata yang berbeda:

1. Hanya Memanggil MCP (Cek Status Pesanan): User menanyakan status pelacakan pesanan nomor 123. Registry menemukan endpoint MCP order management, mengeksekusi get_order_status via Gateway, dan agen selesai tanpa melibatkan agen A2A lain.
2. Kombinasi Multi-Protokol (MCP + A2A untuk Diskon): User menanyakan tier diskon untuk pembelian barang tertentu. Lewat satu pencarian natural, Registry mengembalikan dua hal sekaligus: MCP order management dan A2A Pricing Agent. Model mengambil detail pesanan dulu via MCP, lalu melempar datanya ke Pricing Agent untuk analisis diskon.
3. Pencarian Semantik Murni (Retur dan Refund): User ingin mengembalikan barang pesanan 789. Menariknya, kata "return" atau "refund" sama sekali nggak tercantum di nama Customer Support Agent. Tapi berkat pencarian hibrida semantik dan kata kunci di deskripsi registry, agen tersebut berhasil ditemukan dan dipanggil dengan tepat.

Kapan Sebaiknya Memakai dan Menghindari Pola Ini?

Meski runtime discovery terdengar sangat fleksibel, AWS mengingatkan bahwa pola ini nggak wajib dipakai di semua proyek AI.

Kamu sangat dianjurkan memakai AWS Agent Registry kalau sistemmu memenuhi kondisi ini:

• Punya puluhan hingga ratusan API internal lintas divisi.
• Tim produk ingin mendeploy tools baru secara mandiri tanpa harus berkoordinasi mengubah kode orkestrator pusat.
• Perlu tata kelola ketat dan audit trail terkait tool apa saja yang boleh diakses publik maupun internal.

Sebaliknya, hindari runtime discovery jika:

• Katalog Tools Sedikit dan Stabil: Kalau agenmu cuma butuh 3 atau 4 tools yang jarang berubah, hardcoded biasa jauh lebih simpel dan hemat latensi jaringan.
• Alur Kerja Kaku (Fixed Pipeline): Kalau urutan pemanggilan tools selalu pasti (misalnya: A lalu B lalu C), buat saja sebagai alur deterministik kaku agar pemantauan tracing jauh lebih mudah.

Kalau kamu butuh model reasoning canggih buat membangun sistem multi-agent semacam ini lewat API yang fleksibel tanpa kartu kredit luar negeri, kamu bisa mencoba model seperti Claude Sonnet 4.6 (Rp2.700 / Rp13.500 per 1 juta token) atau Claude Sonnet 5 (Rp3.210 / Rp15.750 per 1 juta token) lewat Classai Router.

Dampak Nyata Buat Developer dan Arsitektur AI di Indonesia

Buat tim engineering dan startup di Indonesia yang lagi gencar membangun asisten digital enterprise, kehadiran AWS Agent Registry membawa angin segar. Pertama, arsitektur microservices internal yang biasanya terpecah di berbagai tim kini bisa diintegrasikan ke sistem AI secara teratur tanpa kekacauan dependensi.

Kedua, dari sudut pandang kepatuhan dan keamanan data (selaras dengan prinsip UU Pelindungan Data Pribadi), pola pemisahan kredensial ini sangat krusial. Registry hanya menyimpan katalog dan metadata fungsi, sedangkan akses token rahasia tetap berada di brankas konfigurasi internal perusahaan. Tim keamanan bisa mencabut izin suatu tool cukup dengan mengubah status record di registry tanpa perlu merombak aplikasi utama.