Kita sudah sering membicarakan tentang kerangka agen. LangGraph, CrewAI, AutoGen, berbagai SDK, loop, pemanggilan alat, memori, perencana, kritikus, supervisor. Semua kata-kata yang berguna, demi kebaikan. Namun semakin saya melihat agen yang sebenarnya digunakan, semakin saya merasa bahwa bagian menariknya telah berpindah ke bawah level kerangka kerja.

Pertanyaannya bukan lagi sekedar: perpustakaan mana yang saya gunakan untuk membuat model langkah berpikir?

Pertanyaan sebenarnya adalah: di mana agen ini tinggal ketika dia berhenti menjadi demo?

Karena agen yang serius bukanlah fungsi yang memanggil model dan mengembalikan teks. Ini adalah sistem terdistribusi kecil. Itu harus membaca konteks, menggunakan alat, mengeksekusi kode, menyentuh file, mengingat keputusan, meminta izin, gagal dengan baik, memulai ulang, meninggalkan log, tidak membakar anggaran dan tidak berubah menjadi buldoser di dalam repositori produksi.

Kerangkanya adalah roda kemudi. Prasarananya adalah jalan, rem, bengkel, asuransi dan orang yang mengetahui dimana kuncinya.

Karena sekarang sedang banyak dibicarakan

Pada tahun 2023 dan 2024, perbincangan sangat berpusat pada model. LLM yang mana? Berapa banyak konteksnya? Harganya berapa? Seberapa baik dia dalam pemrograman?

Pada tahun 2025 dan 2026 pembicaraan telah bergeser. Modelnya cukup baik untuk melakukan pekerjaan nyata, tetapi itulah sebabnya bagian-bagian yang membosankan menjadi terlihat: runtime, keamanan, konektor, identitas, observabilitas, eksekusi kode, penerapan, rollback.

Ini adalah transisi alami dari sihir ke teknik.

Ketika agen hanya perlu memberikan respons, obrolan saja sudah cukup. Saat Anda perlu membuka pull request, menanyakan database, memanggil CRM, memulai pekerjaan, menavigasi situs, membaca Slack, mengompilasi kode, dan memperbarui dokumen, Anda memerlukan sistem operasi yang mampu menanganinya.

Tidak dalam arti harfiah. Dalam arti organisasi.

Bagian pertama: runtime di mana agen dapat bertahan

Seorang agen sering kali bekerja secara bertahap. Lihatlah keadaannya, pilih tindakan, gunakan alat, amati hasilnya, perbarui rencana, ulangi.

Jika loop ini berada di dalam satu permintaan HTTP, Anda akan segera mengalami masalah. Beberapa tindakan lambat. Beberapa menunggu masukan manusia. Ada yang gagal dan harus dicoba lagi. Beberapa harus bertahan dalam penerapan atau batas waktu.

Di sinilah alur kerja yang tahan lama, antrean, latar belakang pekerjaan, dan mesin negara ikut berperan. Mereka tidak glamor, tapi itulah perbedaan antara agen yang terlihat pintar dalam demo dan agen yang bisa Anda tinggalkan sambil minum kopi.

Bagi saya runtime agen harus menjawab pertanyaan yang sangat konkret:

• di mana saya menyimpan status antara satu langkah dan langkah lainnya?
• apa yang terjadi jika prosesnya terhenti di tengah jalan?
• bolehkah aku berhenti sejenak dan meminta persetujuan?
• bisakah saya memutar ulang larinya untuk memahami mengapa dia membuat pilihan itu?
• dapatkah saya membatasi durasi, memori, alat, dan biaya?

Vercel berusaha keras dalam hal ini dengan AI SDK, fungsi, alur kerja, dan alat untuk membangun agen dalam aplikasi web. Tapi intinya bukan hanya Vercel. Intinya adalah agen memerlukan rumah operasional, bukan titik akhir tunggal.

Bagian kedua: sandbox, karena agen harus bisa kotor tanpa pecah

Segera setelah agen menulis kode atau menjalankan perintah, kotak pasir diperlukan.

Tampaknya seperti kata teknis, tetapi idenya bersifat domestik: Anda memberinya meja kerja. Itu dapat membuka file, menginstal dependensi, menjalankan tes, melakukan eksperimen, menghasilkan output. Jika dia salah, Anda sudah menanggung kerugiannya. Jika berhasil, promosikan hasilnya.

Kotak pasir agen harus memiliki beberapa properti:

• sistem file terisolasi;
• CPU, memori dan batas waktu;
• jaringan yang dikendalikan;
• rahasia dipasang hanya bila diperlukan;
• log lengkap;
• kemungkinan untuk mengekspor artefak;
• bersihkan reset di antara proses, bila perlu.

Vercel Sandbox berjalan tepat ke arah ini: lingkungan terisolasi untuk menjalankan kode, menginstal dependensi, bekerja dengan file, dan menghasilkan artefak tanpa menjalankan semuanya di runtime aplikasi utama.

Hal ini lebih penting daripada yang terlihat. Banyak prototipe agen yang melompat langsung dari model ke sistem nyata. Model dapat memanggil alat. Alat dapat melakukan banyak hal. Semuanya tampak elegan sampai perintah pertama yang salah, ketergantungan pertama dipasang di tempat yang salah, token pertama yang berakhir di log.

Kotak pasir adalah cara orang dewasa untuk mengatakan: silakan, tapi di sini.

Bagian ketiga: MCP dan masalah konektor

Model Context Protocol telah menjadi salah satu bagian ekosistem yang paling menarik karena mencoba menstandardisasi sesuatu yang dengan cepat menjadi tidak dapat dikelola: bagaimana model menemukan dan menggunakan alat eksternal.

Tanpa standar, setiap integrasi hanyalah sebuah pulau kecil. Konektor untuk GitHub dilakukan dengan satu cara, satu untuk Slack dilakukan dengan cara lain, satu untuk database dengan semantik berbeda, satu untuk otomatisasi browser yang sepertinya tidak ada apa-apanya.

MCP mengusulkan bahasa umum antara klien dan server: alat, sumber daya, petunjuk, otorisasi, transportasi, penemuan. Hal ini tidak secara ajaib memecahkan masalah tata kelola dan keamanan, namun memberikan tata bahasa.

Dan tata bahasa itu penting. Ketika seorang agen dapat terhubung ke banyak alat, pertanyaannya bukan hanya “bisakah dia melakukannya?”. Persoalannya adalah “apakah dia paham apa yang bisa dia lakukan, dengan batasan apa, atas nama siapa, dan meninggalkan jejak apa?”.

Bagi saya MCP tidak hype karena "melakukan pemanggilan alat". Kami sudah melakukan itu. Ini populer karena menggeser pusat gravitasi dari integrasi tunggal ke katalog alat operasional.

Dalam arsitektur agen yang baik, MCP menjadi semacam panel patch:

• GitHub untuk kode dan masalah;
• Slack untuk konteks percakapan;
• Linear atau Jira untuk pekerjaan yang direncanakan;
• database hanya-baca untuk analitik;
• browser atau scraper yang dikontrol untuk situs eksternal;
• penyimpanan dokumen;
• lingkungan eksekusi yang terisolasi;
• sistem internal diekspos dengan izin yang ketat.

Bagian tersulitnya adalah katalog alat yang bebas kebijakan hanyalah cara yang lebih elegan untuk menciptakan kekacauan.

Bagian keempat: identitas dan izin

Di sinilah banyak demo yang menutup mata.

Seorang agen bertindak atas nama seseorang. Jadi harus jelas siapa yang menjadi subjek tindakannya.

Apakah itu menggunakan izin pengguna? Dari akun layanan? Dari ruang kerja? Apakah Anda memiliki akses sementara atau permanen? Bisakah Anda membaca semuanya atau hanya beberapa sumber? Bisakah kamu menulis? Bisakah Anda membatalkan? Bisakah dia mengirim pesan kepada orang sungguhan?

Jika Anda tidak menjawab pertanyaan-pertanyaan ini dengan baik, cepat atau lambat Anda akan membangun asisten dengan kunci rumah dan tidak ingat siapa yang memberikannya.

Aturan praktis yang saya suka adalah ini: agen harus mampu melakukan lebih sedikit dari manusia, tidak lebih dari manusia. Dan ketika dia harus melakukan sesuatu yang lebih berisiko, dia harus berhenti dan bertanya.

Ini berarti OAuth, cakupan token, pengelolaan rahasia, log audit, kebijakan alat, daftar yang diizinkan, langkah persetujuan. Bukan hal yang sangat romantis. Hal-hal yang diperlukan.

Bagian kelima: memori dan konteks, tetapi tanpa mengumpulkan sampah

Agen membutuhkan memori, tetapi memori menjadi berbahaya jika menjadi loteng.

Setidaknya ada tiga jenis memori:

• jalankan memori: apa yang terjadi dalam eksekusi ini;
• memori proyek: konvensi, keputusan, batasan;
• memori pribadi atau tim: preferensi, nada, ritual, proses.

Memasukkan semuanya ke dalam prompt adalah jalan pintasnya. Ini berfungsi sampai tidak berfungsi lagi. Memori yang berguna harus dijaga: diindeks, diperbarui, kedaluwarsa, diverifikasi, dibuat dapat dikutip.

Agen yang ingatannya buruk lebih buruk daripada agen yang tidak ingat. Karena dia berbicara dengan percaya diri.

Oleh karena itu infrastruktur harus mencakup pengambilan, file instruksi, basis pengetahuan, penyematan bila diperlukan, tetapi juga pembersihan. Kita butuh budaya ingatan: apa yang masuk, siapa yang menyetujuinya, kapan pembusukannya, bagaimana cara memperbaikinya.

Bagian keenam: observabilitas, evaluasi, dan pemutaran ulang

Jika agen membuat kesalahan, log "yang disebut model" tidaklah cukup.

Anda ingin melihat rutenya. Konteks apa yang dia terima? Alat apa saja yang tersedia? Alat mana yang Anda pilih? Dengan argumen apa? Apa tanggapan yang Anda dapatkan? Berapa biayanya? Di mana itu macet? Apakah manusia menyetujui sesuatu? Apakah model kesalahan, alat, prompt, data, atau kesalahan izin?

Di sini agen lebih mirip sistem terdistribusi daripada chatbots.

Anda memerlukan jejak yang dapat dibaca, bukan hanya log teks. Anda harus bisa memutar ulang larinya. Penting untuk membandingkan dua versi agen yang sama pada tugas yang diketahui. Kita perlu mengukur regresi: tidak hanya "menjawab lebih baik", tetapi juga "menutup tiket yang tepat tanpa menyentuh file yang tidak diminta".

Evaluasi agen lebih sulit dibandingkan evaluasi teks karena mencakup tindakan. Membandingkan string yang diharapkan saja tidak cukup. Anda harus melihat urutan, efek samping, kualitas artefak, waktu, biaya, jumlah intervensi manusia.

Lucunya, kami selalu kembali ke sana: rekayasa perangkat lunak. Tes, lingkungan, jejak, rollback. Kecuali bahwa kode sekarang juga memutuskan apa yang harus dilakukan selanjutnya.

Bagian ketujuh: antarmuka manusia

Agen tidak harus hanya sekedar live chat.

Beberapa agen membutuhkan papan. Lainnya halaman dengan status dan log. Lainnya dari tombol "setujui". Lebih banyak komentar sebaris. Yang lain lagi dari CLI.

UI mengubah perilaku. Jika satu-satunya cara untuk mengendalikan agen adalah dengan menulis pesan yang panjang, pengguna akan memberikan instruksi yang tidak jelas kepada agen. Namun jika dia melihat rencana, perbedaan, sumber, risiko, dan tindakan selanjutnya, dia bisa melakukan intervensi dengan tepat.

Infrastruktur agen yang layak mencakup permukaan kontrol:

• status saat ini;
• rencana yang dapat diedit;
• artefak yang dihasilkan;
• berbeda;
• permintaan persetujuan;
• kronologi;
• tombol berhenti;
• tombol coba lagi;
• izin yang terlihat.

Tampaknya sepele, tapi sebenarnya tidak. Perbedaan antara "AI yang menyeramkan" dan "asisten yang andal" sering kali hanya pada "asisten yang andal" yang menunjukkan di mana ia berada.

Tumpukan mental

Jika saya menggambarnya hari ini, tumpukan agen minimumnya adalah ini:

1. Model: penalaran, pembangkitan, pemanggilan alat, multimodal jika perlu.
2. Orkestrasi: loop, langkah, perencana, kebijakan, human-in-the-loop.
3. Waktu proses yang tahan lama: alur kerja, antrian, coba lagi, jeda, lanjutkan.
4. Sandbox: eksekusi kode, sistem file terisolasi, batasan, artefak.
5. Lapisan alat: MCP, API internal, browser, database, repositori.
6. Lapisan identitas: OAuth, cakupan, rahasia, audit, kebijakan.
7. Lapisan memori: konteks proyek, pengambilan, instruksi, kedaluwarsa.
8. Observabilitas: metrik penelusuran, pemutaran ulang, evaluasi, biaya dan kualitas.
9. Permukaan produk: ngobrol bila cukup, dasbor bila diperlukan, tinjau jika penting.

Kerangka agenik terutama mencakup poin 2 dan sebagian dari poin 1. Selebihnya adalah karya nyata.

Apa yang akan saya lakukan dalam latihan

Jika sebuah tim mengatakan kepada saya “kami menginginkan agen dalam produksi,” saya tidak akan memulai dengan sepuluh agen.

Saya akan mulai dengan alur kerja yang kecil, berulang, dan dapat diamati. Misalnya: membuka PR pemeliharaan, memperbarui dokumentasi dari masalah yang sudah ditutup, menyiapkan tinjauan mingguan, melakukan triase bug duplikat, membuat pengujian untuk file yang terpengaruh.

Kemudian saya akan menetapkan batasan yang sangat jelas:

• tidak ada tulisan tanpa cabang atau kotak pasir;
• tidak ada rahasia di prompt;
• alat dalam daftar yang diizinkan;
• persetujuan manusia atas tindakan eksternal;
• pencatatan dan penelusuran wajib;
• anggaran per proses;
• keluaran selalu dapat diperiksa.

Only then would I expand.

Agen tidak gagal hanya karena modelnya salah. Mereka gagal karena kami menempatkannya di lingkungan yang tidak jelas, dengan izin yang membingungkan dan ekspektasi teatrikal.

Bacaan saya

Infrastruktur agen sangat membosankan.

Bukan bagian yang membuat Anda bertepuk tangan dalam demo. Ini adalah bagian yang memungkinkan Anda menggunakan demo pada Senin pagi, dengan orang-orang nyata, data nyata, dan konsekuensi nyata.

Masa depan agen tidak hanya ditentukan oleh siapa yang memiliki panutan terbaik. Hal ini akan ditentukan oleh siapa pun yang membangun tempat terbaik untuk membuatnya bekerja: terisolasi saat ia bereksperimen, terhubung saat diperlukan, selalu dapat diamati, diberi wewenang dengan kriteria, dan cukup rendah hati untuk berhenti saat ia tidak mengetahuinya.

Di situlah agen berhenti menjadi mainan dan menjadi infrastruktur.

Sources

• Vercel: Cara membangun agen AI dengan Vercel dan AI SDK
• Vercel Docs: Kotak Pasir
• Vercel Docs: Bekerja dengan Sandbox
• Dokumen Vercel: MCP
• Protokol Konteks Model: Spesifikasi
• OpenAI: Alat baru untuk agen bangunan
• Blog Cloudflare: Agen di Cloudflare