Selamat datang di selanjutnya, teman-teman lainnya. Bayangkan Anda menjalankan sebuah perusahaan dan mempekerjakan tim spesialis hebat perencanaan perjalanan kelas dunia, pakar orientasi karyawan, dan staf dukungan TI. Namun, tak saat ini berbicara, setiap kali ada tugas yang membutuhkan dua orang dari mereka, Anda harus berjalan di antara meja dan membawa informasi itu sendiri. Begitulah cara kerja sebagian besar agen AI saat ini. Mereka beroperasi secara terisolasi bahkan ketika masalah tersebut jelas membutuhkan kerja tim. Jadi, hari ini kita akan membahas bagaimana agen dapat berkomunikasi, menyerahkan pekerjaan dan bertindak seperti tim sungguh, Samir Kapiters. Ini bukan konsep masa depan. Orkestrasi multi-agen sudah terjadi saat ini. Dan ini didukung oleh protokol yang disebut A2A. Kita akan mulai dengan masalahnya, membedah protokol tersebut bagian demi bagian, dan melihat bagaimana Microsoft menggunakannya di dalam Kopet Studio dan Azure Air.

Ambil kopi Anda dan mari kita mulai. Jadi, apa masalah sebenarnya? Agen AI saat ini persis seperti spesialis yang terisolasi tersebut. Masih memiliki pengetahuan alat dan tujuannya sendiri. Agen cuaca mengetahui perkecah. Agen hotel mengetahui ketersediaan kamar, tetapi mereka tidak berbagi apapun. Sekarang, bayangkan seorang pengguna meminta perjalanan ke Seattle minggu depan dengan hotel di dekat kantor. Satu agen harus menjadi pakar cuaca, pakar perjalanan, dan pakar bisnis lokal sekaligus. Itu berarti perintah prom yang sangat besar dan memungkak yang memaksakan setiap kemampuan ke dalam satu sistem dan perintah tersebut terus-menerus-menerus. Solusi lama adalah kode kustom. Anda menulis jembatan antara agen cuaca dan agen hotel, lalu satu lagi antara agen hotel dan agen penerbangan, dan satu lagi untuk agen kalender. Awalnya berhasil, tetapi setiap kali Anda menambahkan agen baru, Anda membangun integrasi lain.

Segera Anda akan memiliki mimpi buruk koneksi point-to-point yang rumit di mana satu perubahan merusak segalanya. Peningkatan produktivitas yang seharusnya diberikan oleh AI Anda bisa dimakan oleh pekerjaan pemeliharaan. Mari kita lihat masalah bisnis yang sebenarnya. Organisasi Anda sudah memiliki proses dengan serah terima pekerjaan. Sebuah tiket dibuat, seseorang menyeleksinya, seseorang menyelesaikannya, seseorang mencatatnya, dan setiap langkah adalah serah terima. Di dunia lama, Anda mengotomatiskan setiap langkah dengan agen terpisah lalu menghabiskan waktu berminggu-minggu untuk menghubungkan. Tetapi bagaimana jika ada protokol yang memungkinkan agen untuk saling menemukan dan bekerja sama tanpa jembatan kustom? Itulah tepatnya yang dilakukan A2A. Dalam bahasa sederhana, A2A adalah cara standar bagi agen untuk saling berbicara, mengopor pekerjaan, dan menyelesaikan sesuatu sebagai tim.

Apa itu A2A? Definisi sederhananya. A2A adalah singkatan dari agent to agent. Ini adalah protokol terbuka yang memungkinkan agen-agen AI berkomunikasi langsung satu sama lain terlepas dari siapa yang buat. Anda bisa menganggapnya seperti HTTP untuk agen? HTTP adalah bahasa yang digunakan perambahan web dan server untuk berkomunikasi dan A2A melakukan hal yang sama untuk agen. Agen yang dibuat oleh tim TI Anda di Microsoft Copilot Studio dapat berbicara dengan agen yang dibuat oleh perusahaan lain di Google Cloud selama keduanya menggunakan A2A. Ini juga bukan proyek kecil. A2A disponsori oleh delapan perusahaan besar termasuk Google, Microsoft, Cisco, Salesforce, SAP, dan lainnya serta dihosting oleh Linux Foundation Takti. Versi satu teknik yang stabil dan siap untuk digunakan secara nyata yang berarti tidak ada vendor tunggal yang mengendalikan protokol ini. Ini bukan milik Google atau Microsoft.

Ini adalah industri. Desainnya sengaja dibuat sederhana. A2A dibangun di atas standar web yang ada seperti HTTP dan JSON-RPC, hal-hal yang sudah diketahui oleh setiap pengembang. Tidak ada yang eksotis atau berpemirisan. Itu membuatnya mudah diadopsi oleh perusahaan tanpa harus membongkar infrastruktur mereka yang sudah ada. Anda mungkin pernah mendengar protokol lain yang disebut MCP atau model konteks protokol. Berikut pedaannya. MCP adalah agen ke alat, artinya protokol ini menghubungkan agen ke sumber data eksternal dan API. Adalah agen ke agen yang menghubungkan agen langsung satu sama lain. Keduanya bukan bersaing, melainkan saling lengkap. Anggap MCP sebagai koneksi vertikal dari agen ke alatnya dan A2A sebagai koneksi horizontal antar agen yang berdampingan. Lagi pilihan desain. A2A memperlakukan agen sebagai entitas yang pulang. Jadi ke satu agen berbicara dengan agen lain, ia tidak melihat penalaran internal, alat, atau data pribadi agen tersebut.

Ia hanya melihat tugas yang dikirimnya dan hasil yang didapatkan kembali. Hal itu menjaga privasi dan kekayaan elektrik. Agen cuaca tidak perlu tahu bagaimana agen hotel mesan kamar, ia hanya perlu memberikan perakhiran cuaca. Sekarang mari kita lihat bagian pertama dari tegak-teki ini, yaitu kartu agen. Kartu agen, yaitu resume. Setiap agen yang kompatibel dengan A2A menerbitkan sesuatu yang disebut kartu agen. Kartu tersebut adalah dokumen yang dapat dibaca mesin yang berada di URL standar di domain agen, khususnya di path well-known agent card, jason. Jika Anda tahu di mana lokasi agen tersebut, Anda dapat mengambil kartunya dan mempelajari semua yang perlu dengar. Anggap kartu agen sebagai resume atau kartu nama. Kartu ini memberitahu ke yang lain siapa Anda lakukan. Kartu tersebut berisi nama agen, deskripsi teks biasa tentang kemampuannya, dan teks keterampilan yang membantu dalam penemuan.

Ini juga mencantumkan URL titik akhir tempat ia menerima permintaan, persyaratan autentikasi, serta format input dan output yang diterimanya. Berikut adalah contoh konkret. Katakanlah Anda miliki agen spesialis. Kartu agen yang berbunyi, saya dapat menyediakan cuaca saat ini dan perakhiran 5 hari untuk kota manapun. Ia mencantumkan titik akhir apinya karena ia menerima nama kota dan mengembalikan suhu serta kondisi dalam format jason. Hanya itu saja. Ini hanyalah pernyataan yang jelas tentang apa yang bisa dilakukannya tanpa mengungkap rahasia atau logika internal. Penemuan pekerja seperti ini. Agen orkestrator memiliki daftar URL agen yang dikenal atau Anda dapat mengonfigurasinya dengan URL tersebut. Saat tugas masuk, orkestrator mengambil kartu agen, membaca deskripsinya, dan memutuskan agen mana yang paling cocok. Kartu cuaca menyebutkan cuaca, jadi tugas cuaca diarahkan ke sana. Kartu hotel menyebutkan hotel, jadi tugas hotel diarahkan ke sana.

Perhatikan bahwa tidak diperlukan registri pusat. Agen tidak perlu mendaftar ke direktori global. Mereka hanya menerbitkan kartu mereka di lokasi yang diketahui, dan agen lain yang mengetahui URL tersebut dapat menemukannya. Itu adalah pilihan desain yang disengaja agar sistem tetap terdesentralisasi dan fleksibel. Anda dapat menambahkan spesialis baru ke jaringan Anda dengan memberikan URL-nya kepada orkestrator dan penemuan terjadi secara teman. Jadi orkestrator tahu siapa yang tersedia. Namun bagaimana mereka benar-benar menyerahkan pekerjaan? Bagaimana komunikasi A2A pekerjaan? Jadi orkestrator tahu agen mana yang tersedia melalui kartu agen. Namun bagaimana agen-agen ini benar-benar saling menyerahkan pekerjaan? Desbannya sederhana. Semua komunikasi terjadi melalui HTTP menggunakan pesan JSON-RPC protokol yang sama yang mendukung sebagian besar layanan web saat ini. Tidak ada yang custom atau rumit, hanya lalu lintas web standar yang mengalir di antara dua agen.

Ini masalahnya, tidak semua tugas sama. A2A mendukung tiga pola interaksi berbeda tergantung pada apa yang Anda butuhkan. Respons instan menangani pencarian cepat, di mana agen jarak jauh dapat menjawab segera. Anda mengirim permintaan, ia langsung membalas dan Anda selesai. Meminta perakhiran cuaca hari ini kepada agen cuaca bekerja persis seperti ini. Balasan asinkron, masuk dan keluar. Streaming menangani tugas yang lebih lama. Mungkin agen spesialis perlu mencari di beberapa basis data atau menjalankan analisis yang rumit. Aliham buat Anda menunggu satu respons, agen mengirim kembaran status saat bekerja menggunakan peristiwaan dikirim server. Anda mendapatkan laporan kemajuan di sepanjang jalan, lalu hasil akhir muncul di akhir. Melacok pengiriman paket bekerja dengan cara yang sama. Anda melihat setiap langkah satu terjadi. Pemberitahuan asinkron menangani tugas yang berjalan lama, di mana agen jarak jauh mungkin memerlukan waktu beberapa menit, jam, atau bahkan hari.

Onboarding karyawan adalah contoh yang bagus. Satu spesialis menyediakan akun IT, sementara yang lain menangani pendaftaran tunjangan selama beberapa hari. Agen klien mengirimkan permintaan, mendapatkan ID tugas kembali, dan melanjutkan pekerjaannya. Nantinya, agen jarak jauh mengirimkan hasilnya melalui web. Klien juga dapat meriksa kemajuan kapan saja dan melakukan polling pada ID tugas tersebut. Setiap interaksi mengikuti struktur yang sama, semuanya diatur sebagai tugas. Saat klien mengirimkan permintaan, agen jarak jauh membuat tugas dan mengembalikan ID tugas. ID tersebut menjadi penanda pelacakan untuk semua yang terjadi setelahnya. Pesan di dalam tugas itu memiliki peran memberi tahu siapa pengirimnya, dan bagian-bagian yang bisa berupa teks biasa. Data binar seperti gambar atau dokumen, payload JSON, atau URL yang mengarah ke file yang disimpan di tempat lain. Autentikasi mengikuti konvensi web standar OAUT kunci APA token bearer.

Hal-hal yang biasa tidak ada yang baru untuk dipelajar di sini. Kartu agen memberi tahu klien metode autentikasi mana yang harus digunakan, dan klien menanganinya dengan cara yang sama seperti panggilan api lainnya. Beginilah bentuknya dalam praktek. Katakanlah orkestrator membutuhkan data cuaca untuk sebuah perjalanan. Ia mengirimkan tugas ke spesialis cuaca. Spesialis cuaca mengakui permintaan tersebut, memulai pemrosesan, dan melakukan streaming pembaruan kembali. Mengambil data. Mengurai hasil. Kemudian ia mengirimkan pelakiran akhir. Orkestrator tidak pernah melihat alat internal agen cuaca, kunci APA, atau proses penalarannya, atau proses. Ia hanya melihat keluarannya. Itu adalah prinsip desain utama. Batasan yang bersih antar agen dan tidak ada status internal yang bocor keluar. Namun A2A saja tidak cukup. Anda membutuhkan pos yang cerdas untuk mengordinasikan semua spesialis. Hal itu membawa kita pada pola spesialis orkestrator.

Pola spesialis orkestrator. Di sini lah semuanya terhubung. Pola spesialis orkestrator adalah arsitektur yang paling umum dalam sistem multi-agen produksi saat ini. Bayangkan seperti perusahaan dengan departemen, IT, HR, keuangan masing-masing menangani bidangnya sendiri. Anda memiliki pengambil keputusan pusat yang merutekan pekerjaan ke tim khusus. Dan setiap tim fokus pada apa yang mereka lakukan dengan baik. Orkestrator memegang gambaran besar. Ia menerima permintaan pengguna, mencari tahu apa yang perlu dilakukan, dan memutuskan spesialis mana yang dapat menangani setiap bagian. Jika pengguna bertanya, rencanakan perjalanan ke Seattle minggu depan. Orkestrator tidak memesan penerbangan atau memeriksa hotel sendiri. Ia tahu ada spesialis penerbangan, spesialis hotel, dan spesialis cuaca. Ia memecah permintaan tersebut menjadi bagian-bagian itu dan mendirikan sikap. Setiap spesialis memiliki fokus yang sempit.

Satu agen menangani pemesanan penerbangan, yang lain menangani pencarian hotel, dan yang ketiga menangani triasins. Mereka tidak perlu mengetahui domain satu sama lain. Spesialis penerbangan, maskapai ruta, dan harga. Ia tidak perlu tahu apapun tentang jenis kamar hotel atau kebijakan pembatalan. Fokus yang sempit itu membuat setiap agen sederhana mudah dirawat dan mudah diuji. Inilah bagian pentingnya. Orkestrator tidak mengeksekusi tugas tersebut. Ia merutakan pekerjaan dan menggabungkan. Itulah satu-satunya tugas. Peran orkestrator adalah menjadi pengatur yang cerdas, bukan agen super yang mencoba melakukan segalanya. Saat Anda membiarkan orkestrator mulai mengerjakan tugas spesialis, Anda kehilangan seluruh manfaat dari pola lain. Sistem itu kembali menjadi kekacauan umulit. Waspadalah terhadap kesalahan umulit. Beberapa tim membuat domain spesialis yang tumpang tindih. Dua agen sama-sama mengklaim, bisa menangani dukungan pelanggan atau pencarian data, yang menciptakan kebingungan perutean.

Orkestrator tidak tahu mana yang harus dipilih, dan pengguna mendapatkan hasil yang tidak konsisten. Perbaikannya cukup mudah. Setiap spesialis memiliki domain yang dibatasi dengan jelas tanpa tumantin. Jika dua agen bisa melakukan hal yang sama, gabungkan mereka atau bagi domainnya dengan lebih bersih. Copilot Studio dari Microsoft menggunakan pola ini secara asli. Copilot utama Anda bertindak sebagai orkestrator, sementara agen turunan dan agen yang terhubung bertindak spesialis. Saat pengguna meminta sesuatu yang mencakup berbagai domain, Copilot utama mendelegasikannya ke spesialis yang tepat melalui A2A. Ini sudah ada dalam platform, jadi Anda tidak perlu membuat logika orkestrasi dari awal. Manfaat besar di sini adalah modularitas. Perlu mengganti penyedia pemesanan hotel Anda. Ganti spesialis hotel tanpa menyentuh orkestrator atau agen lainnya. Menambahkan kemampuan baru. Buat spesialis baru, daftarkan ke orkestrator dan selesai.

Setiap agen tetap kecil, mudah dikelola, dan dapat diterapkan secara mendiri. Itulah inti dari beralih dari agen monolitik ke sistem multi-agen. Jadi kita punya protokol kartu agen dan polanya. Mari kita lihat aksinya dalam skenario-nya. Contoh nyata A2A dalam tindakan. Jadi seperti apa sebenarnya A2A di dunia nyata? Mari kita mulai dengan contoh sederhana. Anda memberitahu asisten AI Anda. Rencanakan perjalanan ke Seattle minggu depan. Dalam cara lama, satu asisten itu harus tahu segalanya. Cuaca, penerbangan, hotel, restoran, sekaligus. Itu terlalu banyak untuk diminta dari satu klit. Dengan A2A, orkestrator Mojah. Ia mengirim tugas ke spesialis cuaca untuk menanyakan perakiraan untuk hari-hari tersebut. Pada saat yang sama, ia meminta spesialis penerbangan untuk mencari penerbangan yang tiba selasa pagi kembali kamis malam, dan spesialis hotel untuk mencari tempat dekat pusat kota Seattle untuk tiga malam.

Setiap spesialis bekerja secara mandiri. Dan mereka tidak perlu berbicara dengan agen lain, karena mereka masing-masing memiliki sumber data, alat, dan kealian sendiri. Orkestrator mengumpulkan semua hasil dan menggabungkannya menjadi satu tanggap. Pengguna melihat satu jawaban tunggu. Ini perakhirannya. Ini adalah pilihan penerbangan Anda dan ini ada tiga hotel yang dekatkan. Di balik layar, tiga agen terpisah bekerja bersama tanpa kode integrasi custom apapun. Sekarang sekarang ada bisnis. Katakanlah ada tiket masuk. Laptop saya tidak bisa terhubung ke VPN. Orkestrator menyimpulkan ini adalah masalah jaringan. Ia menyerahkan tiket tersebut kepada spesialis runbook yang mengetahui langkah-langkah standar. Periksa status klien VPN, verifikasi kredensial jaringan, mulai ulang layanan. Spesialis itu mengembalikan langkah. Kemudian orkestrator meneruskan hasilnya ke spesialis penulis tiket yang mencatat resolusi dalam sistem.

Semua ini terjadi dalam hitungan detik tanpa campur tangan manusia, dan tim IT hanya terlibat jika langkah otomatis tidak memperbaiki masalah. Orientasi karyawan adalah contoh lain, tetapi yang ini memakan waktu berhari-hari, bukan detik. Karyawan baru bergabung dengan proses. Orkestrator memicu spesialis IT untuk membuat akun dan menetapkan perangkat keras yang mungkin memakan waktu beberapa jam. Pada saat yang sama, ia memicu spesialis tunjangan SDM untuk formulir pendaftaran, dan kemudian spesialis fasilitas untuk akses meja dan lencana. Setiap spesialis menjalankan tugas jangka panjangnya sendiri secara mandiri, dan orkestrator melacak kemajuan menggunakan ID tugas yang kita bicarakan sebelumnya. Jadi, jika spesialis IT selesai, orkestrator mengetahuinya, dan jika spesialitas terlambat, ia bisa menindak lanjutinya. Nah, pengguna melihat satu alur orientasi yang lancar, namun di balik layar ini adalah tim terkoordinasi yang bekerja selama beberapa hari.

Dan ini bukan sekadar teori. Coca-Cola Beverages Africa sudah menggunakan Aigen Copel Studio dengan dinamik 365 untuk mengotomatiskan siklus perencanaan. Perencanaan mereka biasanya menghabiskan waktu hingga 1,5 jam setiap hari untuk tugasnya guru. Dengan orkestrasi multi-agen, siklus tersebut berjalan dengan sendiri. Orkestrator mendelegasikan kepada spesialis, yang menangani berbagai bagian dari proses perencanaan rantai pasokan. Hasilnya adalah penghematan waktu lebih dari 1 jam per orang setiap hari hanya dengan membiarkan Aigen saling berkomunikasi alih-alih membuat manusia, alih-alih membuat manusia antar sistem. Jadi polanya sama dalam semua contoh ini. Setiap Aigen adalah pakar mandiri yang mengetahui domininya sendiri dan memiliki alatnya sendiri, serta tidak perlu tahu apapun tentang Aigen lainnya. A2A menyediakan lapisan komunikasi sederhana sehingga mereka dapat pekerja sama tanpa kode khusus.

Anda mendapatkan protokol standar dan orkestrator cerdas tanpa jembatan, tanpa integrasi point-to-point, dan tanpa meliharaan. Microsoft telah sepenuhnya mendukung hal ini. Mari kita lihat di mana Copilot Studio dan Azure AI berperan. Ekosistem Microsoft, Copilot Studio, dan Azure AI. Nah di mana posisi Microsoft dalam semua ini? Tepat di tengah-tengahnya. Copilot Studio kini mendukung A2A secara asli dan telah tersedia secara umum sejak April 2006. Itu bukan peran tinggi atau beta. Fitur ini sudah siap produksi dan pelanggan yang memenuhi syarat dapat menggunakannya hari ini. Begini masalahnya. Anda dapat menghubungkan Aigen eksternal ke orkestrator Copilot Studio Anda. Saat saya katakan eksternal, maksud saya benar-benar eksternal. Agen yang dibangun di Google Cloud, AWS, atau platform lain manapun yang mendukung protokol A2A. Orkestrator tidak peduli di mana agen berada atau kerangga kerja apa yang digunakan untuk membangun.

Selama mendukung A2A, agen tersebut dapat bergabung dengan pengaturannya sederhana. Di Copilot Studio Anda membuat sesuatu yang disebut agen terhubung. Anda menempelkan URL endpoint agen tersebut. Copilot Studio secara otomatis mengambil kartu agen dari URL tersebut yang merupakan file JSON kartu agen yang kita bahas sebelumnya. Sistem membaca kemampuan agen, persyaratan autentikasi, serta format input dan output. Kemudian sistem membangun konektor kustom di latar belakang dan orkestrator Anda dapat langsung mendelegasikan tugas. Anda tidak perlu pekerja integrasi manual atau kode khusus. Cukup tempel URL-nya dan selesai. Di sisi Azure, Azure Eye Foundry Agent Service juga mendukung A2A. Layanan ini memiliki endpoint IP A2A khusus yang menginginkan orkestrator sumber terbuka seperti autogen, link chain, dan semantik kernel memanggil agen foundry. Jadi, jika Anda telah membangun agen menggunakan kerangka kerja tersebut, Anda dapat menghubungkannya ke ekosistem Microsoft tanpa menulis ulang apapun.

Ini adalah hubungan dua arah. Microsoft mengikuti pola orkestrator spesialis yang sama seperti yang telah kita jelaskan. Agen utama di Copilot Studio bertindak sebagai orkestrator, sementara agen turunan dan agen terhubung bertindak sebagai spesialis. Masing-masing menangani domain sendiri, dan orkestrator mengarahkan serta menggabungkan hasil. Ini adalah arsitektur yang sama, hanya saja berjalan di platform Microsoft. Namun, ada beberapa batasan yang perlu Anda ketahui. Pertama, setiap lompatan orkestrasi tambahan akan menambah latensi. Jika agen utama Anda memanggil agen terhubung, dan agen terhubung itu memanggil spesialis lain, setiap lompatan menambah waktu jaringan. Untuk percakapan waktu nyata, terlalu banyak lompatan dapat membuat pengalaman terasal. Kedua, delegasi berlebihan menciptakan kekacauan perhutian. Jika Anda memiliki terlalu banyak spesialis dengan domain yang tumpang tindih, orkestrator akan mulai membuat keputusan perhutian yang buruk.

Jadi, jaga jumlah spesialis Anda agar tetap bisa dikelola dan pisahkan domain Anda dengan jelas. Ketiga, ada batasan khusus terkait agen data Fabric. Agen tersebut tidak berfungsi saat agen utama diterapkan ke Microsoft di Gerasna Kopel. Jika penerapan Anda menargetkan MT kan tepat, mengencanakan tepat. Kendala ini nyata namun bisa dikelola. Platform ini sudah cukup matang untuk penggunaan produksi, dan Microsoft aktif berupaya menutup celah tersebut. Sekarang mari hubungkan semua poin dan lihat gambar-gambar. Bagian koneksi, bagaimana semuanya saling melengkap. Mari mundur secenak dan melihat bagaimana bagian ini terhubung. Adalah sistem telepon yang digunakan agen untuk saling menelpon. Laptop agen itulah buku telepon Anda. Kartu ini menunjukkan siapa yang harus digunakan dan apa yang ditangani setiap agen. Orkestrator adalah resepsionis yang mengarahkan setiap panggilan ke departemen yang tepat.

Tidak satu dari bagian ini bekerja sendiri. Anda membutuhkan ketiganya. Tanpa buku telepon Anda tidak tahu siapa yang harus digunakan. Tanpa resepsionis, tidak ada yang mengatur lalu lintas. Dan tanpa sistem telepon, resepsionis tidak bisa menghubungkan siapapun. Mereka hanya bekerja sebagai tim. Disitulah modularitas berperan. Saat spesialis Anda bersifat modular, Anda bisa menambah kemampuan baru tanpa merusak apa yang sudah berjalan. Katakanlah, Anda ingin menambahkan spesialis penyewaan mobil ke asisten perjalanan Anda. Anda membuatnya, menerbitkan kartu agennya dan memberikan kartu agennya ke orkestrator. Spesialis penerbangan dan spesialis hotel tetap sama persis. Orkestrator pun tidak berubah. Anda cukup memasukkan bagian baru dan sistem akan disiakan. Karena protokolnya terbuka, Anda tidak akan terjebak dengan satu vendor. Orkestrator Anda bisa berjalan di Copilot Studio. Egen cuaca Anda bisa berada di Google Cloud.

Egen hotel Anda di AWS. Sistem internal Anda tetap di Azure. Mereka semua berbicara bahasa yang sama. Itulah keindahan standar terbuka. Hal ini mencegah ketergantungan pada vendor dan memungkinkan Anda memilih alat terberi untuk set pekerjaan. A2A bukan tentang membangun satu agen super cerdas yang tahu segalanya. Ini tentang membangun tenaga kerja spesialis yang fleksibel yang bisa Anda atur ulang saat kebutuhan Anda. Anda tidak mengganti agen Anda. Anda mengatur ulang mereka. Anda menambahkan yang baru. Anda menukar yang lama. Sistem tumbuh bersama Anda alih-alih menjadi penghambat. Apa yang bisa dilakukan dengan pengetahuan ini hari ini? Paling penting yang bisa dititik. Malah dengan kecil. Pilih satu proses berulang di organisasi Anda yang melibatkan banyak sistem. Misalnya penyelesaian tiket, onboarding karyawan, atau pelaporan pengeluaran. Sesuatu dengan serah terima yang jelas antar langkah.

Kemudian buat prototipe dengan satu orkestrator dan dua spesialis. Anda tidak memerlukan arsitektur yang... Anda hanya butuh contoh kerja yang bisa Anda pelajari. Gunakan alat yang sudah mendukung ini. Copel Studio memiliki dukungan A2A bawaan. Azure AI Foundry pun demikian. Anda tidak perlu membangun protokol dari awal atau menulis kode integrasi custom. Tempelkan URL, konfigurasikan agen Anda, dan mulailah mendelegasikan. Waspada kendala-kendala umum. Pastikan domain spesialis Anda tidak tumal ini. Jika dua agen bisa melakukan hal yang sama, gabungkan atau bagi domainnya dengan lebih rapi. Biarkan orkestrator menangani perlutenan, bukan eksekusi. Dan perhatikan latensi dari lompatan orkestrasi. Jika waktu respons Anda mulai meningkat, mungkin ada terlalu banyak lapisan delegasi. Langkah pertama yang terbaik adalah yang sedang. Tetakan serah terima dalam alur kerja Anda yang ada. Di mana informasi diteruskan antar orang atau antar sistem.

Itulah titik di mana agen dapat mengambil alih. Setiap serah terima adalah sebuah peluang. Jadi itulah sistem A2A secara singkat. Tiga bagian sederhana yang bekerja bersama. Agen tidak lagi terisolasi dan mulai bertindak seperti tim sungguhan. Pilih satu alur kerja dengan serah terima yang jelas dan bangun dari sana. Berlanggananlah untuk penjelasan yang lebih sederhana dan beri komentar jika ada yang dipahami.