Merekayasa Agen AI yang Membangun dan Merilis Software Nyata: Arsitektur Jobbit

Sebagian besar "agen AI" berhenti di percakapan. Mereka menjawab, lalu manusia yang mengerjakan pekerjaannya. Masalah rekayasa yang menarik — dan benar-benar sulit — adalah membangun agen yang mengerjakan pekerjaan itu sendiri: menulis aplikasi full-stack, menjalankannya, memperbaiki kesalahannya sendiri, dan men-deploy-nya ke produksi. Itulah masalah yang setiap hari dikerjakan oleh tim engineering di Jobbit dan divisi R&D-nya, Jobbit Labs (jobbitlabs.com).

Tulisan ini adalah pembahasan teknis mendalam tentang pola di balik agen AI yang membangun dan merilis software — arsitekturnya, mode kegagalannya, dan pelajaran yang didapat. Tulisan ini sengaja dibuat praktis dan tidak terikat pada penyedia tertentu: baik Anda membangun di atas LLM, orkestrasi multi-agen, tool calling, maupun RAG, prinsip-prinsip ini tetap berlaku.

Chatbot menjawab; agen bertindak

Lompatan dari chatbot ke agen adalah lompatan dari menghasilkan teks menjadi mengambil tindakan di dunia nyata. Sebuah agen harus merencanakan tugas multi-langkah, memanggil tool, membaca hasilnya, dan memutuskan langkah berikutnya — lalu mengulanginya hingga tujuan tercapai. Loop itu, yang sering disebut agentic loop (atau loop reason–act), adalah jantung dari sistem ini.

Tantangan rekayasanya adalah setiap langkah bisa gagal. Model bisa berhalusinasi memanggil fungsi yang tidak ada, menulis kode yang tidak bisa dikompilasi, salah membaca output sebuah tool, atau diam-diam melenceng dari tugas. Chatbot yang keliru menghasilkan kalimat yang buruk; agen yang keliru menghasilkan deploy yang rusak. Keandalan, bukan kemampuan mentah, adalah pekerjaan rekayasa yang sesungguhnya.

Arsitekturnya: planner, executor, tools

Platform agen yang tangguh memisahkan perencanaan (planning) dari eksekusi (execution). Lapisan perencanaan memecah sebuah tujuan ("bangun aplikasi pemesanan dengan pembayaran") menjadi langkah-langkah konkret; lapisan eksekusi menjalankan setiap langkah menggunakan tools. Memisahkan kedua urusan ini membuat sistem mudah di-debug: Anda bisa memeriksa rencananya secara terpisah dari bagaimana setiap langkah dijalankan.

Tool use adalah tempat sebuah agen memperoleh "tangannya". Tool adalah fungsi yang terdefinisi jelas yang bisa dipanggil model — membaca file, menulis kode, menjalankan build, mengkueri database, men-deploy. Disiplin rekayasa di sini adalah desain antarmuka: setiap tool membutuhkan skema yang ketat dan tidak ambigu, input yang tervalidasi, serta output terstruktur yang bisa di-parse model dengan andal. Antarmuka tool yang longgar adalah sumber utama kegagalan agen; antarmuka yang ketat adalah kemenangan keandalan termurah yang tersedia.

Untuk pekerjaan kompleks, satu agen sering kali digantikan oleh orkestrasi multi-agen — agen-agen terspesialisasi yang merencanakan, menulis kode, mereview, dan memverifikasi, yang dikoordinasikan oleh sebuah orkestrator. Dekomposisi memberi Anda fokus (setiap agen punya tugas dan konteks yang sempit) dan paralelisme (subtugas independen berjalan bersamaan). Imbal baliknya adalah overhead koordinasi, jadi lapisan orkestrasi harus deterministik di tempat yang memungkinkan dan tahan banting di tempat yang tidak.

Menjalankan dan men-deploy kode nyata, secara aman

Agen yang menulis software harus menjalankan software itu — dan menjalankan kode yang dihasilkan model adalah masalah keamanan sebelum menjadi hal lainnya. Jawabannya adalah eksekusi kode sandbox (sandboxed code execution): kode tak terpercaya dijalankan di lingkungan terisolasi dengan sumber daya terbatas, tanpa akses ke secret, dan dengan batas jaringan yang ketat. Sandbox itulah yang memungkinkan agen untuk beriterasi — kompilasi, uji, baca error, perbaiki — tanpa membahayakan platform atau pengguna lain.

Deployment adalah langkah yang mengubah aplikasi yang dihasilkan menjadi sebuah produk. Sebuah AI app builder yang sebenarnya menguasai seluruh jalur dari kode menjadi URL aktif: build, menyediakan hosting, memasang domain, menterminasi TLS. Merekayasa ini dengan baik berarti membuat deploy yang dapat diulang dan dapat dibalik (repeatable and reversible) — input yang sama menghasilkan hasil yang sama, dan deploy yang buruk bisa di-rollback. Idempotensi dan rollback yang bersih memang tidak terlihat keren, tetapi itulah yang membuat deployment otonom layak dipercaya.

Konteks, memori, dan retrieval

LLM memiliki konteks yang terbatas, dan proyek nyata tidak muat di dalamnya. Maka sistem agen yang serius berinvestasi besar pada context engineering: menentukan apa yang dilihat model di setiap langkah. Menjejalkan segalanya ke dalam prompt itu mahal sekaligus kontraproduktif — terlalu banyak konteks yang tidak relevan justru menurunkan kualitas penalaran.

Di sinilah RAG (retrieval-augmented generation) dan vector database menunjukkan nilainya. Alih-alih membuang seluruh basis kode ke dalam konteks, sistem mengambil beberapa file, simbol, atau dokumen yang relevan dengan langkah saat ini. Dikombinasikan dengan memori terstruktur — catatan keputusan, spesifikasi yang terus berkembang, dan apa saja yang sudah dicoba — retrieval menjaga agen tetap membumi sepanjang tugas yang panjang tanpa membludakkan jendela konteks. Retrieval yang baik sering kali menjadi tuas kualitas yang lebih besar daripada model yang lebih besar.

Keandalan: eval, verifikasi, dan guardrail

Jika ada satu gagasan yang membedakan rekayasa agen tingkat produksi dari sekadar demo, gagasan itu adalah: Anda tidak bisa merilis apa yang tidak bisa Anda ukur. Sistem agentik bersifat stokastik, jadi keandalan direkayasa melalui eval — rangkaian uji otomatis yang menilai agen pada tugas-tugas representatif dan menangkap regresi sebelum pengguna mengalaminya. Perubahan yang "terasa lebih baik" tetapi menjatuhkan skor eval Anda adalah perubahan yang tidak Anda rilis.

Di atas eval terdapat guardrail runtime dan verifikasi. Pola yang paling efektif adalah self-checking adversarial: setelah agen menghasilkan sesuatu — sepotong kode, sebuah rencana, sebuah perbaikan — sebuah lintasan verifikasi terpisah mencoba membantah-nya. Apakah kodenya bisa dikompilasi? Apakah testnya lulus? Apakah outputnya sesuai skema? Memperlakukan verifikasi sebagai langkah tersendiri yang skeptis menangkap sebagian besar kegagalan yang akan terlewat jika hanya mengandalkan satu lintasan yang penuh percaya diri. Retry dengan backoff, circuit breaker, dan eskalasi ke manusia menangani sisanya.

Observability yang bisa Anda debug

Ketika sebuah sistem otonom membuat puluhan keputusan per tugas, Anda perlu melihatnya. Observability — tracing terstruktur atas setiap prompt, panggilan tool, dan hasil — bukanlah hal yang bisa ditawar. Saat agen melakukan kesalahan, trace itulah cara Anda menemukan langkah pasti yang melenceng, mereproduksinya, dan memperbaiki akar masalahnya. Tim engineering yang memperlakukan trace agen sebagai telemetri kelas utama men-debug dalam hitungan menit; tim yang tidak melakukannya men-debug dalam hitungan hari.

Edge dan skala elastis

Beban kerja agen bersifat meledak-ledak (bursty) dan sensitif terhadap latensi, yang membuat edge computing menjadi pasangan alami. Menjalankan dekat dengan pengguna — di platform seperti Cloudflare Workers dan penyimpanan data edge — memangkas latensi bolak-balik dan menskala secara elastis mengikuti permintaan. Jobbit Labs mengandalkan pendekatan edge-first ini untuk sebagian infrastruktur data dan produknya: terdistribusi global, autoscaling, dan bayar sesuai pemakaian, sehingga kapasitas mengikuti beban alih-alih menganggur.

Lapisan human-in-the-loop

Bagian terakhir dari arsitektur adalah bagian yang paling sering tidak dimiliki platform agen lain: jalur human-in-the-loop. AI menangani volume dan kecepatan, tetapi beberapa keputusan — logika yang sensitif terhadap keamanan, redaksi hukum, pertimbangan desain — adalah ranah manusia. Merekayasa ini berarti membangun titik serah terima (handoff) yang bersih, tempat seorang pakar manusia tepercaya bisa turun tangan, dengan escrow yang melindungi transaksi. Agen dan jaringan manusia bukanlah lapisan yang saling bersaing; keduanya adalah jaring pengaman yang dirancang sejak awal yang membuat keseluruhan sistem aman untuk diandalkan.

Pelajaran bagi engineer yang membangun agen

Jika Anda membangun sistem agentik, beberapa prinsip ini akan mengembalikan investasi Anda berkali-kali lipat.

Rancang antarmuka tool yang ketat. Sebagian besar kegagalan agen berakar pada tool yang ambigu. Skema yang ketat dan I/O yang tervalidasi adalah keandalan termurah yang akan pernah Anda beli.

Verifikasi secara adversarial. Jangan percaya lintasan pertama yang penuh percaya diri. Tambahkan langkah terpisah yang tugasnya membantah hasil tersebut.

Ukur dengan eval. Bangun perangkat eval sebelum Anda menskalakan agen. Anda tidak bisa memperbaiki apa yang tidak bisa Anda nilai.

Rekayasa konteks, jangan dijejalkan. Ambil yang relevan; ingat yang penting. Prompt yang lebih besar bukan berarti prompt yang lebih baik.

Sandbox semua yang tak terpercaya. Jika sebuah agen menjalankan kode, isolasi adalah prasyarat, bukan fitur tambahan.

Sediakan jalur untuk manusia. Sistem otonom yang paling aman adalah sistem yang tahu kapan harus bertanya kepada manusia.

Pertanyaan yang sering diajukan

Apa yang membedakan agen AI dari chatbot?

Chatbot menghasilkan teks; sebuah agen AI merencanakan dan mengambil tindakan — memanggil tool, menjalankan kode, dan beriterasi menuju sebuah tujuan. Kesulitan rekayasanya adalah keandalan di sepanjang banyak langkah, di mana satu kesalahan saja bisa merusak hasil akhir.

Bagaimana cara menjalankan kode hasil AI secara aman?

Dengan eksekusi kode sandbox (sandboxed code execution): kode tak terpercaya dijalankan di lingkungan terisolasi dengan sumber daya terbatas, tanpa akses secret, dan jaringan yang dibatasi, sehingga agen bisa mengompilasi, menguji, dan memperbaiki tanpa risiko terhadap platform.

Mengapa eval begitu penting bagi sistem agen?

Karena agen bersifat stokastik, Anda membutuhkan eval otomatis untuk mengukur kualitas pada tugas-tugas representatif dan menangkap regresi sebelum dirilis. Tanpanya, "perbaikan" hanyalah tebakan.

Apa yang dikerjakan Jobbit Labs?

Jobbit Labs (jobbitlabs.com) adalah divisi R&D dan data di balik Jobbit, yang berfokus pada rekayasa yang lebih berat, intensif data, dan berskala enterprise — riset, platform data, dan fondasi agen tempat produk ini dibangun.

Penasaran dengan rekayasa di balik agen yang merilis software? Jelajahi jobbit.uk dan jobbitlabs.com.