Sebagian besar tim AI yang ingin meningkatkan kinerja agen menggunakan strategi yang sama: jendela konteks lebih besar, lebih banyak dokumen, dan prompt lebih cerdas. Artikel ini berpendapat bahwa naluri tersebut sepenuhnya keliru. Unsur yang kurang bukanlah lebih banyak informasi. Melainkan kendali. Lapisan kendali yang dirancang dengan baik membedakan agen yang hanya berfungsi dalam demo dari agen yang berfungsi di lingkungan produksi.
Memberi agen AI memori lebih besar, lebih banyak dokumen, atau jendela konteks lebih panjang tidak membuatnya lebih cerdas—hanya lebih lambat dan mahal. Peningkatan nyata berasal dari mengajari agen untuk memilih apa yang dibutuhkan saat dibutuhkan, alih-alih mengonsumsi semuanya sekaligus.
Keandalan berasal dari loop, bukan model. Perbedaan antara agen yang mengesankan dalam demo dan agen yang tangguh di lingkungan produksi bukanlah kualitas AI-nya, melainkan apakah sistem memeriksa pekerjaannya sendiri. Agen yang merencanakan, bertindak, mengamati, dan memverifikasi setiap langkah dapat menemukan kesalahannya sendiri, alih-alih melakukan kekeliruan dengan penuh keyakinan.
Sebagian besar agen AI saat ini pada dasarnya hanyalah chatbot dengan langkah tambahan—tanpa mekanisme untuk mengetahui apakah prosesnya sudah benar, kapan harus berhenti, atau kapan harus mencoba pendekatan lain. Menambahkan lapisan kendali yang tepat—kriteria keberhasilan yang jelas, status terstruktur, dan pemeriksaan validasi—akan mengubah sesuatu yang sekadar menyerupai agen menjadi sistem yang benar-benar dapat dipercaya.
Apa yang Anda makan untuk makan siang kemarin?
Anda mungkin tidak memutar ulang setiap ingatan sepanjang hidup hingga menemukan “kemarin + makan siang”. Anda langsung menuju bagian pengalaman tempat konsep-konsep tersebut tersimpan. Itulah model mental yang berguna untuk membangun agen:
Jendela konteks yang sangat besar bukanlah memori.
Tumpukan dokumen yang diambil bukanlah pemahaman.
Rantai pemikiran yang panjang bukanlah keandalan.
Semua itu hanyalah bahan. Namun, hal yang membuat agen terasa seperti agen sama dengan hal yang membuat otak Anda tidak menelusuri seluruh riwayat hidup secara paksa: kendali.
Sebuah survei terbaru—Agentic Reasoning for Large Language Models—berhasil merangkum (dan menamai) perubahan yang dirasakan banyak dari kita saat membangun sistem: dari penalaran di dalam model menjadi penalaran melalui interaksi. Tulisan ini bukan ringkasan makalah tersebut. Tulisan ini mencoba menerjemahkan perubahan tersebut menjadi desain sistem praktis:
Jika Anda membangun agen seperti chatbot dengan alat, Anda akan terus menghadapi pola kegagalan chatbot—hanya saja kesalahannya lebih mahal.
Selama beberapa waktu, pedoman standar untuk “membuat model lebih cerdas” pada dasarnya adalah: prompt yang lebih baik, rantai pemikiran, konsistensi mandiri/peningkatan berbasis sampling, dan mungkin sedikit pencarian.
ReAct menjadi titik balik karena membuat “pemikiran → tindakan → pengamatan” terasa alami. Namun, perhatikan batasan tersiratnya: banyak pendekatan ini tetap berujung pada “inferensi one-shot, tetapi dengan lebih banyak token”. Survei tersebut menawarkan kerangka yang lebih tajam: penalaran agentik menekankan penskalaan interaksi pada waktu pengujian—mengubah inferensi menjadi proses iteratif yang terus melibatkan model, memori, dan lingkungan.
Jika Anda pernah membangun (atau menggunakan) agen yang mengesankan dalam demo tetapi rapuh dalam alur kerja nyata, tulisan ini untuk Anda.
Izinkan saya menjelaskan pola yang sering saya lihat (dan jelas pernah saya bangun sendiri dalam berbagai versi):
Gunakan model Chat yang baik
Tambahkan beberapa alat (pencarian, kueri basis data, mungkin eksekusi kode)
Tambahkan RAG
Tambahkan prompt sistem “you are an autonomous agent”
Bungkus semuanya dalam while-loop hingga berhenti atau kehabisan waktu
Selamat, Anda memiliki sesuatu yang menyerupai agen. Namun, sistem itu cenderung gagal dengan pola yang dapat diprediksi:
Konteks membengkak: setiap pengamatan ditambahkan; prompt berubah menjadi lapisan-lapisan arkeologis.
Asal mencoba alat: “memakai alat yang salah dengan penuh keyakinan” menjadi pola kegagalan utama.
Tanpa kondisi berhenti: proses terus berjalan karena bisa, bukan karena seharusnya.
Tanpa disiplin grounding: sistem tidak menyadari kesalahannya kecuali Anda memaksanya.
Memori = riwayat Chat: pada dasarnya hanya menulis log lalu menyebutnya pembelajaran.
Inilah sebabnya “agen” sering terasa ajaib dalam demo, tetapi berantakan di lingkungan produksi. Pengalaman kami menerapkan sistem agentik di lingkungan produksi juga menunjukkan hal ini: setelah yang dievaluasi bukan lagi model, melainkan sistem, pola kegagalannya mencakup navigasi, kedisiplinan penggunaan alat, pemangkasan konteks, dan desain evaluasi—bukan sekadar “apakah model menjawab dengan benar”.
Jadi, pertanyaannya menjadi: seperti apa agen yang dirancang dengan benar?
Agar tidak terlalu abstrak, berikut contoh sederhana alur kerja yang mudah dibayangkan: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Implementasi umum yang “menyerupai agen” biasanya seperti ini:
Langsung mengambil banyak dokumen kebijakan maskapai/perjalanan (meskipun belum ada yang diperlukan).
Memanggil alat pencarian, menempelkan daftar panjang hasil ke dalam prompt, lalu “memilih salah satunya”.
Memesan terlalu dini tanpa memverifikasi batasan (waktu kedatangan/bagasi/kursi/kebijakan).
Jika gagal, sistem mencoba lagi dengan cara yang sedikit berbeda, tetapi tanpa memahami dengan jelas apa yang berubah atau dipelajari.
Masalahnya bukan model tidak dapat melakukan penalaran, melainkan sistem tidak mengendalikan alur kerja.
Versi yang lebih agentik memperlakukan tugas sebagai proses interaktif dengan status dan pemeriksaan yang eksplisit:
RENCANAKAN: nyatakan ulang batasan + cantumkan informasi yang belum tersedia (misalnya, “which airport preference?” / “is 1 stop ok?”).
BERTINDAK: panggil pencarian penerbangan dengan kueri terstruktur (rentang tanggal, batas waktu kedatangan, anggaran).
AMATI: simpan hasil dalam objek status yang ringkas (5 kandidat teratas beserta harga/waktu tiba/transit), bukan tumpukan teks besar yang ditempelkan begitu saja.
PERBARUI: sempurnakan kueri jika batasan tidak terpenuhi (misalnya, “arrival before 6pm is too strict—widen time window or raise budget?”).
VERIFIKASI: jalankan validator (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
BERHENTI: hanya setelah API pemesanan mengembalikan konfirmasi dan semua validator lolos.
Perubahannya tampak kecil, tetapi sangat menentukan. Pengambilan informasi dilakukan secara kondisional (bukan refleks), konteks dikelola (status terstruktur, bukan terus ditumpuk), dan verifikasi menjadi bagian dari loop (bukan diserahkan kepada pengguna). Ganti “memesan penerbangan” dengan “membuat pesanan pembelian”, “menerbitkan pengembalian dana”, “mengubah konfigurasi produksi”, atau “merilis PR”, dan prinsipnya tetap sama: setelah agen dapat bertindak, loop lebih penting daripada prompt.
Survei di atas membagi penalaran agentik menjadi tiga lapisan: fundamental (perencanaan/penggunaan alat/pencarian), berkembang mandiri (umpan balik + memori), dan kolektif (koordinasi multiagen).
Namun, gagasan yang lebih mendalam adalah bahwa penalaran menjadi prinsip utama untuk mengatur perencanaan, pengambilan keputusan, dan verifikasi—bukan sekadar menghasilkan rantai pemikiran yang tampak masuk akal. Hal itu terdengar abstrak sampai Anda memetakannya ke perubahan dalam arsitektur. Ada tiga poin utama yang perlu diingat:
Agen yang baik tidak seharusnya menganggap pengambilan informasi sebagai sesuatu yang “selalu dilakukan”. Mengambil informasi adalah keputusan, bukan refleks.
Berikut heuristik praktisnya:
Jika sistem Anda mengambil informasi di setiap giliran, Anda bukan membangun mekanisme pengambilan informasi, melainkan menciptakan pajak konteks.
Hal ini selalu muncul dalam pekerjaan nyata. Saat men-debug insiden produksi, Anda tidak memasukkan semua log ke dalam konteks; Anda menentukan metrik/log yang perlu diambil berikutnya berdasarkan hipotesis saat ini. Itulah “pengambilan informasi agentik”. Berikut pola yang lebih konkret:
Tentukan apakah Anda perlu mengambil informasi
Jika ya: susun kueri, ambil, telaah sekilas, ekstrak
Jika bukti bertentangan: ambil lagi
Baru setelah itu lakukan sintesis
Di sinilah “RAG agentik” mulai berbeda dari RAG tradisional: pengambilan informasi menjadi langkah penalaran yang disengaja, bukan tahapan alur yang dijalankan secara default.
Begitu Anda berhenti mengevaluasi “model” dan mulai mengevaluasi “sistem”, pelacakan status dan penelusuran menjadi penting.
Satu hal yang kini makin diperjelas oleh industri adalah observabilitas alur kerja agen. Misalnya, Agents SDK dari OpenAI dilengkapi penelusuran bawaan dan dasbor Traces yang merekam proses agen (pembuatan output, pemanggilan alat, serah terima, pagar pengaman, peristiwa khusus), sehingga Anda dapat men-debug dan mengaudit kejadian langkah demi langkah.
Itu bukan sekadar “fitur tambahan”. Itulah pembeda antara sistem yang dapat di-debug dan sistem yang hanya dapat dinilai berdasarkan kesan.
Menurut saya, bagian survei yang paling mudah ditindaklanjuti adalah pembahasannya yang lugas tentang umpan balik. Survei itu membagi umpan balik menjadi tiga pola: umpan balik reflektif (hasilkan → kritik → revisi), adaptasi parametrik (belajar melalui fine-tuning/RL), dan umpan balik berbasis validator (coba lagi hingga lolos validator).
Sebagian besar tim sebaiknya memulai dengan umpan balik berbasis validator karena pendekatan ini sederhana dan efektif. Jika Anda dapat menulis validator apa pun yang menjalankan pengujian unit, memeriksa skema, menetapkan aturan/kendala bisnis (“pengembalian dana di atas X harus dieskalasikan”), atau memastikan kebenaran faktual (“wajib menyertakan kutipan”), Anda dapat mengubah output model yang nondeterministik menjadi sesuatu yang benar-benar dapat dipercaya.
Salah satu perubahan yang sebelumnya sama sekali tak terduga di sini sebenarnya sederhana: di dunia agen, keandalan sering kali lebih ditentukan oleh loop daripada model.
Berikut disiplin loop paling sederhana yang saya temukan untuk meningkatkan perilaku secara andal tanpa pelatihan:
Jalankan secara bertahap: Rencanakan → Bertindak → Amati → Perbarui,
Setelah setiap tindakan, rangkum pengamatan dalam 1–3 poin,
Berhenti saat kriteria keberhasilan terpenuhi atau batas anggaran tercapai; kembalikan hasil terbaik yang diketahui beserta ketidakpastian yang tersisa.
Tujuannya bukan membuat model bertele-tele. Tujuannya adalah membuat sistem mudah dipahami dan memaksanya “bersentuhan dengan kenyataan” pada setiap langkah. Contoh yang sangat relevan bagi engineer adalah grounding loop tertutup ala CI:
Rencanakan: usulkan daftar perubahan
Bertindak: jalankan pengujian/lint
Amati: uraikan kegagalan
Perbarui: terapkan patch dan coba lagi
Beberapa pertanyaan berikut cenderung mengungkap desain agen yang tidak disengaja:
“Apakah agen saya memilih apa yang perlu diambil, atau saya selalu mengambil informasi?”
Jika pengambilan informasi selalu dilakukan, Anda harus menanggung latensi, biaya, pengenceran konteks, dan risiko lebih tinggi bahwa masukan sampah menghasilkan keluaran sampah.
“Dapatkah agen saya menyadari bahwa jawabannya salah?”
Jika satu-satunya sinyal umpan balik agen Anda adalah “pengguna merasa kesal”, berarti Anda menjalankan RL dengan penderitaan manusia. Loop percobaan ulang berbasis validator adalah cara paling rapi untuk mengujinya terhadap kenyataan.
“Apakah memori dapat ditulisi dan terus membaik seiring waktu?”
Jika “memori” Anda hanya menambahkan riwayat percakapan, pada dasarnya Anda sekadar menulis log. Cara survei tersebut membingkai memori penting untuk dicermati: memori menjadi konteks yang tumbuh secara dinamis dan terus disempurnakan agen, bukan sekadar transkrip.
Log memberi tahu apa yang terjadi, sedangkan memori memberi tahu apa yang harus dilakukan lain kali. Riwayat Chat adalah transkrip. Memori adalah kebijakan yang terus berkembang tentang hal-hal yang layak dibawa ke masa mendatang.
Sebagai permulaan praktis, buat tabel kecil “pelajaran yang dipetik” dengan kunci berupa jenis tugas, alat, dan mode kegagalan, serta nilai berupa hal yang berhasil dan yang harus dihindari. Tujuannya bukan membangun grafik pengetahuan yang sempurna. Tujuannya adalah menciptakan perbaikan yang berlipat: memori + umpan balik mengubah agen dari “asisten tanpa status” menjadi sistem yang makin baik seiring waktu.
Kita mungkin tergoda menambahkan lebih banyak agen untuk menangani masalah, tetapi hal ini sering kali justru melipatgandakan beban koordinasi. Pola “tim minimum yang layak” yang baik:
Koordinator: menguraikan + membagikan tugas
Eksekutor: melakukan pemanggilan alat/perubahan
Kritikus/evaluator: memeriksa kebenaran/risiko
Pengelola memori: menulis/menyeleksi pelajaran
Jika Anda tidak dapat menjelaskan tanggung jawab setiap agen, mungkin Anda belum memerlukan banyak agen.
Jika kita benar-benar menerima perubahan paradigma ini, kita mungkin akan berhenti memasukkan semuanya ke dalam prompt, memperlakukan kegagalan sebagai hasil akhir, dan mengevaluasi agen seperti chatbot. Kita mulai memperlakukan agen sebagaimana adanya: sistem perangkat lunak dengan bahasa sebagai bidang kendali—dan loop sebagai sumber keandalannya.
Sebelum menambahkan model lain, tambahkan loop evaluasi lain. Sebelum mengambil semuanya, jadikan pengambilan informasi bersifat kondisional. Rilis satu validator sebelum merilis sepuluh. Perlakukan memori sebagai keputusan kebijakan, bukan basis data. Saat beralih ke multiagen, mulailah dengan dua agen, bukan dua puluh. Ini bukan aturan, melainkan pola yang terbukti bertahan di lingkungan produksi.