Runtime Kubernetes yang dibangun untuk agen, bukan layanan
Google merilis AX sebagai open source pekan ini, dan mendeskripsikannya dalam README proyek sebagai "orkestrator deklaratif berthroughput tinggi untuk menjalankan miliaran beban kerja agen otonom dalam satu klaster." AX berjalan di atas "Agent Substrate" milik Google, sebuah lapisan eksekusi ter-sandbox, dan proyek ini langsung melesat di Hacker News: unggahan "AX – Google's Open Agentic Orchestrator" meraih 619 poin dan 283 komentar dalam 20 jam pertama, menjadi berita AI teratas di situs itu pada hari tersebut.
Yang membuatnya penting bukan kodenya, yang masih pra-1.0 dan secara terbuka tidak stabil. Yang penting adalah argumen yang dibawa proyek ini lewat keberadaannya: beban kerja agen tidak cocok dengan bentuk yang selama ini dirancang untuk Kubernetes dan sebagian besar orkestrator lain. Sebuah microservice menangani request secara terus-menerus. Sebuah batch job berjalan sampai selesai lalu berhenti. Agen tidak melakukan keduanya — ia bisa diam menunggu menit demi menit menunggu manusia atau sistem eksternal, lalu tiba-tiba membutuhkan komputasi berat, lalu diam lagi, sambil tetap menyimpan state yang harus bertahan sepanjang jeda itu. Situs AX sendiri membingkai ini secara langsung, dengan argumen bahwa sistem orkestrasi tradisional yang dibangun untuk microservice stateless atau batch job tidak cocok untuk agen yang bergantian antara komputasi dan waktu diam yang panjang, dan mengklaim kemampuan melanjutkan agen yang tersuspensi dalam hitungan sub-detik tanpa penalti cold-start.
Terlepas dari apakah Anda akan menjalankan AX atau tidak, kerangka berpikir itu berguna. Ia memberi kosakata untuk masalah yang saat ini banyak diselesaikan tim dengan cara tambal sulam: container keep-alive, dump state ad hoc ke database, cron job yang terus mengecek "apakah agennya sudah selesai?" Jawaban AX adalah menjadikan suspend-and-resume sebagai primitif kelas satu, bukan sesuatu yang ditempel belakangan.
Empat primitif, dan apa yang masing-masing gantikan
AX mengekspos empat objek inti, dan bagian ini layak dipelajari terlepas dari runtime-nya sendiri, menurut README proyek:
Task adalah eksekusi terisolasi dan dapat disuspensi untuk kode agen yang tidak terpercaya. Ini jawaban langsung untuk masalah idle/burst di atas — sebuah Task bisa dijeda di tengah jalan dan dilanjutkan nanti tanpa membayar ulang biaya startup. Saat ini, kebanyakan tim mendekati ini dengan proses worker jangka panjang yang menunggu di antrean, atau fungsi serverless yang menginisialisasi ulang dari nol setiap kali dipanggil. Tak satu pun benar-benar mensuspensi state seperti yang diklaim Task.
Workspace mendeklarasikan repo Git, server MCP, dan skill yang dibutuhkan sebuah agen untuk menjalankan tugasnya. Ini pada dasarnya manifes untuk lingkungan agen, ide yang sama dengan devcontainer.json atau ConfigMap di Kubernetes, tapi khusus untuk apa yang benar-benar disentuh agen coding atau ops otonom — alat-alatnya, bukan sekadar image runtime-nya.
Gateway menegakkan allowlist jaringan eksplisit dan penyuntikan kredensial. Ini boleh dibilang primitif terpenting bagi siapa pun yang menjalankan agen di atas infrastruktur nyata: agen dengan akses jaringan keluar tanpa batas dan kredensial ambient adalah insiden keamanan yang menunggu waktu. Gateway adalah bagian yang biasanya dibangun sendiri lewat egress proxy dan secrets manager, dan menjadikannya sebagai objek yang dideklarasikan alih-alih pengetahuan infrastruktur turun-temurun adalah perbaikan nyata.
Model memusatkan konfigurasi provider LLM dan kredensialnya, sehingga kode agen tidak menuliskan secara hardcode model atau API key mana yang dipanggil. Ini yang paling tidak baru dari keempatnya — banyak platform internal sudah melakukannya — tapi menggabungkannya dengan tiga primitif lain berarti satu manifes mendeskripsikan seluruh lingkup operasi agen: sebagai apa ia berjalan, apa yang bisa ia jangkau, apa yang boleh ia panggil, dan ke mana ia bicara untuk inferensi.
Digabungkan, keempat primitif ini adalah rancangan acuan untuk "infrastruktur native-agen": isolasi dan kemampuan disuspensi (Task), dependensi yang dideklarasikan (Workspace), batas jaringan dan kredensial (Gateway), serta konfigurasi inferensi (Model). Tim yang membangun ini secara manual hari ini biasanya menyelesaikan masing-masing secara terpisah, dengan alat berbeda dan tingkat kedisiplinan berbeda, dan Gateway khususnya yang paling sering dilewatkan saat tenggat mendesak.
Apa yang sebenarnya menghalangi Anda menjalankannya
Menjalankan AX bukan keputusan ringan. Menurut README-nya, syaratnya adalah klaster Kubernetes, alat build ko, registry container, Agent Substrate Control API yang bisa diakses, dan Redis yang di-deploy sebagai bagian dari control plane. Itu komitmen infrastruktur penuh sebelum satu agen pun melakukan pekerjaan berguna, dan justru ini yang memicu kritik paling tajam di thread Hacker News: komentator menunjuk kesenjangan antara pemasaran AX dan kompleksitas setup sebenarnya, mencatat bahwa quickstart-nya saja sudah menuntut beberapa komponen infrastruktur di luar Kubernetes itu sendiri.
Proyek ini juga terbuka soal ketidakmatangannya sendiri. Repositorinya mencantumkan peringatan bahwa timnya "masih aktif menyempurnakan konsep inti, protokol, dan spesifikasi kami" dan kemungkinan akan "memperkenalkan perubahan besar yang tidak kompatibel sebelum rilis stabil." Rilis publik pertama, v0.1.0, diluncurkan 20 Mei 2026, dengan para maintainer menyatakan secara terus terang bahwa mereka "merilis tahap awal ini agar bisa punya percakapan yang konkret" — ini draf diskusi, bukan produk jadi.
Keterusterangan itu tidak menghentikan HN dari mengungkit rekam jejak Google soal developer tools, mengutip transisi Gemini CLI ke Antigravity CLI sebagai preseden untuk alat yang ditinggalkan atau digantikan. Liputan independen mengonfirmasi bahwa AX berlisensi Apache 2.0 dan diposisikan sebagai respons infrastruktur Google terhadap pergeseran dari chatbot ke sistem agen otonom, tapi juga menandai bahwa AX datang tanpa jaminan kompatibilitas mundur. Bagi tim yang mempertimbangkan membangun di atasnya, itulah risiko sebenarnya: bukan soal apakah idenya masuk akal, melainkan apakah API yang Anda integrasikan hari ini masih ada setahun lagi.
Apa yang bisa dilakukan jika belum siap deploy
Jika Anda sudah menjalankan Kubernetes dan bereksperimen dengan agen coding atau ops, jangan mulai dengan mencoba mendirikan seluruh stack AX. Mulailah dengan mengaudit setup Anda saat ini terhadap empat primitifnya. Tanyakan secara spesifik: apakah agen kita punya allowlist jaringan eksplisit dan kredensial yang dibatasi ruang lingkupnya, atau apakah mereka mewarisi apa pun yang bisa dijangkau container host? Itu pertanyaan Gateway, dan itu yang paling layak dijawab terlepas dari orkestrator apa pun yang Anda pakai. Tanyakan apakah dependensi agen — repo, server MCP, akses alat — dideklarasikan di suatu tempat yang bisa dibaca rekan tim, atau apakah itu tersirat dalam Dockerfile yang ditulis enam bulan lalu. Itu pertanyaan Workspace.
Jika jawabannya tidak nyaman, Anda tidak butuh AX untuk memperbaikinya — egress proxy yang dibatasi ruang lingkupnya dengan baik dan satu file manifes sudah memberi sebagian besar manfaat Gateway dan Workspace tanpa perlu stack Kubernetes-plus-Redis-plus-Agent-Substrate. Perlakukan AX sendiri sebagai sinyal ke mana arah infrastruktur agen bergerak dan sebagai latihan penamaan untuk masalah yang sudah Anda hadapi, bukan sebagai dependensi yang harus diadopsi kuartal ini. Tinjau ulang begitu AX melewati versi 1.0 dan peringatan perubahan-yang-tidak-kompatibel hilang dari README-nya — saat itu Anda akan tahu apakah Google masih merawatnya, yang justru pertanyaan yang tidak bisa dijawab thread HN hari ini.
Komentar (0)
Belum ada komentar. Mulai percakapannya.