Foto oleh richard_clyborne di Flickr, CC BY 2.0
Banyak software engineer melihat AI hari ini seperti ombak yang harus dikejar. Tiap bulan ada framework baru, kosakata baru, dan daftar job title baru. Wajar kalau muncul perasaan bahwa pengalaman yang sudah dikumpulkan bertahun-tahun akan segera tidak berguna.
Menurut saya bukan itu yang sedang terjadi. Sebagian besar yang sudah Anda kuasai sebagai software engineer masih berlaku di sistem AI. Contoh paling jelasnya adalah arsitektur, jadi dari situ tulisan ini mulai.
Arsitektur menjawab satu pertanyaan: siapa yang menentukan apa yang terjadi berikutnya.
Jawabannya cuma ada dua, dan keduanya sudah punya nama. Yang pertama orchestration. Satu komponen memegang rencananya dan menyuruh komponen lain mengerjakan bagiannya. Yang kedua choreography. Tidak ada komponen yang memegang rencana. Masing-masing menunggu sesuatu terjadi, lalu bereaksi.
Microservices memakai kedua pola itu. Sistem AI agent juga memakai kedua pola itu. Tidak ada yang baru dari sisi arsitektur. Diagramnya sama dengan diagram yang sudah kita gambar bertahun-tahun.
Yang berubah adalah pelaku di dalam kotaknya.
Service itu deterministik. Kasih input yang sama, hasilnya sama terus, dan kalau gagal pun gagalnya dengan cara yang sama. Agent itu probabilistik. Jawabannya diambil dengan cara sampling dari sebuah model, jadi input yang sama bisa mengambil jalur yang berbeda hari ini dibanding kemarin.
Polanya menentukan siapa yang memegang kendali. Pelakunya menentukan seberapa bisa ditebak hasilnya. Hampir semua perbedaan praktis antara dua dunia itu datang dari pelakunya.
Arsitektur software: orchestration dan choreography
Di orchestration, satu service memegang urutannya. Service itu memanggil payment, lalu stock, lalu shipping. Seluruh alurnya ada di satu tempat dan bisa dibaca dari atas ke bawah. Mengubah alur berarti mengubah satu service itu.
Di choreography, tidak ada service yang memegang urutan. Tiap service menerbitkan event waktu sesuatu terjadi, dan service mana pun yang berkepentingan tinggal berlangganan. Checkout menerbitkan event order, lalu payment dan shipping bereaksi sendiri. Menambah service keempat nyaris tanpa biaya, karena tidak ada yang perlu diberi tahu bahwa service itu ada.
Orchestration dan choreography di arsitektur software
Dua-duanya ada harganya. Orchestration gampang dibaca dan susah dikembangkan, karena semuanya bergantung pada komponen di tengah. Choreography gampang dikembangkan dan susah dibaca, karena alurnya tidak tertulis di mana pun. Untuk mengikutinya, Anda harus membaca semua service dan mengecek event apa yang diterbitkan dan event apa yang didengarkan.
Bedanya terasa di pekerjaan sehari-hari. Alur orchestration itu alur yang bisa diikuti engineer baru di hari pertamanya. Alur choreography itu alur yang dikembangkan tim dalam satu sore, lalu dijelaskan selama seminggu waktu ada yang hilang di tengah jalan. Ada patokan sederhana yang membantu di sini. Pakai orchestration untuk hal yang orang sebut sebagai proses. Pakai choreography untuk hal yang orang sebut sebagai akibat.
Arsitektur AI agent: dua pola yang sama
Di sistem agent yang pakai orchestration, satu komponen membaca pesan masuk dan memutuskan agent mana yang menanganinya. Komponen itu biasanya disebut router atau supervisor, dan dia juga yang menentukan berapa banyak isi percakapan yang boleh dilihat tiap agent.
Di sistem agent yang pakai choreography, tidak ada router. Para agent berbagi satu ruang kerja, sering disebut scratchpad atau shared state. Tiap agent membaca apa yang ada di sana, menambahkan apa yang bisa dia tambahkan, lalu berhenti. Rencananya tidak pernah ditulis. Rencana itu muncul dari urutan siapa yang kebetulan bergerak duluan.
Dua pola yang sama di arsitektur AI agent
Di produksi, versi orchestration yang lebih umum dipakai. Satu intent router duduk di depan sekumpulan domain agent, dan tiap agent punya tool sendiri dan potongan percakapannya sendiri. Desainnya sengaja dibuat tidak heboh, karena harga salah rute itu mahal. Kalau router memilih agent yang salah, orang yang bertanya tidak mendapat jawaban yang dia cari.
Versi choreography kelihatan mengesankan waktu didemokan. Versi itu juga yang bisa berjalan empat belas giliran dan tidak menghasilkan apa-apa, karena tidak ada komponen yang bertanggung jawab atas hasilnya. Di bawah kedua pola itu, para agent tetap harus saling bicara dalam format yang dimengerti kedua pihak. Itu masalah tersendiri dengan sejarahnya sendiri yang panjang.
Yang berbeda adalah pelakunya
Tabel di bawah menaruh dua dunia itu berdampingan. Baris soal siapa yang memegang kendali hampir sama persis. Baris soal bagaimana pelakunya bertingkah tidak.
Arsitektur software dan AI agent dibandingkan, dimulai dari pelakunya
Pelaku deterministik gagal dengan berisik. Service yang salah rute mengembalikan error, dan error itu muncul di trace. Trace-nya cukup untuk menjelaskan apa yang terjadi, karena kode yang jalan adalah kode yang bisa Anda baca di repository. Retry aman kalau panggilannya idempotent, dan hasilnya berhasil atau gagal dengan cara yang sama lagi.
Pelaku probabilistik gagal dengan diam. Agent yang salah rute tetap mengeluarkan jawaban yang lancar dan percaya diri. Tidak ada yang berubah merah. Kegagalannya cuma kelihatan oleh orang yang membaca jawabannya dan cukup paham untuk curiga. Trace kurang menolong di sini, karena yang tercatat adalah apa yang dikatakan agent, bukan kenapa dia mengatakannya. Retry juga tidak mengulang jalannya yang sama. Modelnya sampling lagi, jadi jawaban kedua bisa benar, bisa juga salah dengan cara yang baru. Dua-duanya tidak berarti masalahnya sudah beres.
Karena itu choreography lebih berisiko di agent dibanding di service. Di kedua dunia, choreography menghapus satu tempat di mana rencananya disimpan. Di service, yang hilang terutama keterbacaan. Di agent, yang hilang juga satu-satunya komponen yang tadinya bisa memeriksa jawaban sebelum sampai ke pengguna.
Cara membuat pelaku probabilistik jadi lebih bisa ditebak
Pelakunya tidak bisa dibuat deterministik. Sistem di sekelilingnya bisa. Tiga teknik ini mengerjakan sebagian besar pekerjaannya.
Validation memeriksa jawaban sebelum ada yang memakainya. Outputnya harus cocok dengan schema, membawa semua field yang wajib, dan berada di dalam nilai yang diizinkan. Jawaban yang tidak lolos validation tidak pernah sampai ke pengguna.
Guardrail membatasi apa yang boleh dilakukan agent sebelum dia bergerak. Guardrail menentukan tool apa yang boleh dipanggil, topik apa yang boleh dijawab, dan apa yang harus ditolak. Guardrail mengubah pertanyaan terbuka jadi sekumpulan kecil langkah yang diizinkan.
Verifier memeriksa jawaban sesudahnya, dibandingkan dengan sumber asalnya, pakai aturan atau model kedua. Inilah komponen yang menangkap jawaban salah yang percaya diri tadi.
Tidak ada satu pun dari ini yang membuat modelnya jadi deterministik. Yang terjadi, pemeriksaannya dipindahkan keluar dari model dan masuk ke kode, tempat perilakunya bisa ditebak lagi. Tiap teknik pantas dapat artikel sendiri, dan itu yang akan saya tulis berikutnya.
Kesimpulan
Arsitektur software dan arsitektur AI agent itu arsitektur yang sama. Polanya tidak berubah waktu komponennya mulai memanggil model. Yang berubah cuma pelakunya, dari sesuatu yang deterministik jadi sesuatu yang probabilistik.
Saran praktisnya mengikuti dari situ. Mulai dengan orchestration, karena satu komponen yang memegang rencana adalah satu komponen yang bisa Anda baca. Pindahkan sebagian ke choreography kalau Anda bisa menyebut apa yang bereaksi terhadapnya, dan apa yang terjadi kalau tidak ada yang bereaksi. Di software, pertanyaannya seberapa erat bagian-bagiannya saling bergantung. Di sistem agent ada pertanyaan kedua: kalau satu agent menjawab salah, apakah ada yang menangkapnya sebelum pengguna melihatnya?
Buat software engineer yang sedang pindah ke AI, itu kabar baik. Ilmu arsitekturnya terbawa. Yang perlu dipelajari adalah perilaku pelaku barunya, dan pemeriksaan yang menjaganya tetap jujur.