Lo Udah Baca Chat Terbarunya. Tapi Lo Tetep Ngerjain Rencana Lama.

Ada peneliti yang ngasih nama ke kesalahan ini, karena ternyata AI ngelakuinnya juga — dan di uji coba mereka, tingkat gagalnya 30 dari 30.

Coba bayangin situasi ini.

Bos lo bilang: “Booking ruang meeting buat hari Selasa.”

Lo bikin rencana: pesen Ruang A, Selasa jam 10.

Sepuluh menit kemudian bos ngirim chat: “Eh, ganti jadi Rabu ya.”

Lo baca chat-nya. Lo bales “siap”. Info terbaru udah masuk ke kepala lo.

Terus lo buka sistem booking — dan mesen Ruang A hari Selasa.

Bukan karena lo nggak tau. Lo tau. Cuma rencananya nggak lo ubah.

Nah, itu yang lagi diteliti.

Namanya stale-plan execution

Tiga peneliti — Evan Chen, Shiqiang Wang, dan Christopher G. Brinton — ngasih nama ke pola ini: eksekusi rencana basi.

Konteksnya: tim AI agent yang kerja bareng dan berbagi memori. Urutannya persis kayak cerita di atas:

1. Agent perencana bikin rencana berdasarkan syarat versi ke-3
2. Agent lain ngupdate syaratnya jadi versi ke-4
3. Agent pelaksana nerima versi ke-4 — datanya udah paling baru
4. Tapi dia tetep ngejalanin rencana yang dibikin dari versi ke-3

Kalimat kunci dari paper-nya:

Kesegaran data nggak membuktikan bahwa rencana yang mengizinkan tindakan itu masih sah.

Kenapa ini licik banget

Karena semua alarm pengaman bilang “aman”.

Sistem ngecek: “Datanya udah paling baru?” ✅ Udah.

Terus dia jalan.

Padahal pertanyaan yang bener bukan itu. Pertanyaan yang bener adalah: “Rencana ini dibikin berdasarkan apa, dan apakah dasarnya masih berlaku?”

Dua pertanyaan yang beda. Yang pertama gampang dicek. Yang kedua jarang ada yang ngecek.

Analogi lain yang mungkin lebih kerasa buat orang Jakarta: GPS lo udah nerima data macet terbaru — tapi lo masih ngikutin rute yang dihitung 20 menit lalu, sebelum jalannya ditutup. Datanya seger. Rutenya basi.

Solusinya: PlanFence

Peneliti ini bikin protokol namanya PlanFence. Cara kerjanya tiga langkah:

1. Rencana harus nyebut sumbernya. Waktu agent bikin rencana, dia wajib nyatet data mana persisnya yang dia pakai. Kayak nulis daftar pustaka.

2. Sebelum bertindak, cek ulang — tapi cuma yang relevan. Ini bagian pintarnya. Sebelum ngelakuin tindakan yang keluar ke dunia nyata (kirim email, mesen ruangan, transfer duit), pelaksana ngecek ulang cuma data-data yang bisa ngaruh ke tindakan itu.

Bukan ngecek semuanya. Ngecek semuanya itu lambat dan mahal — apalagi kalau memori bersamanya udah gede banget.

3. Kalau ada yang berubah: bikin ulang rencananya sekali. Kalau nggak bisa diverifikasi: berhenti.

Yang terakhir itu penting. Kalau sistemnya nggak yakin, dia nggak nekat. Dia stop.

Hasilnya

Mereka uji di 30 alur kerja yang di tengah jalan syaratnya diubah.

Sistem biasa — yang cuma ngecek “datanya udah paling baru belum” — ngejalanin rencana basi di SEMUA 30 tugas. Tiga puluh dari tiga puluh.

Dengan PlanFence: nol tindakan yang nggak sah. Semua tugas selesai bener.

⚠️ Tapi ini yang perlu lo baca

Penulisnya sendiri jujur banget soal batasannya, dan gua hargain itu. Kalimat penutup abstraknya:

“Ini adalah hasil keamanan dan biaya sistem dalam kondisi terkendali — bukan peningkatan akurasi tugas secara umum.“

Terjemahannya:

• ✅ Terbukti: protokol ini nyegah tindakan berdasarkan rencana basi, dalam uji coba yang dirancang khusus buat munculin masalah itu
• ❌ Bukan berarti: AI-nya jadi lebih pinter, lebih akurat, atau lebih bagus hasilnya secara umum

Angka 30 dari 30 itu keliatannya dramatis, tapi ingat: uji cobanya emang dirancang supaya masalah itu muncul. Jadi wajar sistem tanpa penangkal gagal semua. Yang dibuktiin adalah penangkalnya bekerja, bukan seberapa sering masalahnya kejadian di dunia nyata.

Dan mereka juga nemu bahwa PlanFence nggak selalu pilihan terbaik. Kalau datanya jarang berubah, pendekatan lain (nyinkronin semua di depan) justru lebih hemat. PlanFence baru menang kalau datanya sering berubah atau memori bersamanya gede banget.

Nggak ada solusi yang menang di semua kondisi. Itu tanda penelitian yang jujur.

Nyambung sama yang lagi rame minggu ini

Kalau lo ngikutin berita AI seminggu terakhir, pola ini kerasa familiar:

• JetStream ngerilis alat yang ngecek izin tiap tindakan agent sebelum dieksekusi
• Meta nambahin fitur di model barunya: minta konfirmasi sebelum tindakan yang nggak bisa dibatalin
• NIST peringatin sistem kontrol identitas jebol gara-gara agent AI
• Sekarang: paper ini, yang nemuin cara lain buat mastiin agent nggak ngelakuin hal berdasarkan alasan yang udah kedaluwarsa

Empat pihak berbeda, satu tema: berhenti sebentar sebelum bertindak, dan pastiin alasannya masih berlaku.

Yang bisa lo pakai

Kalau lo bikin automation multi-langkah — apa pun itu, dari alur konten sampai bot kerjaan — ada satu kebiasaan dari paper ini yang layak ditiru:

Sebelum langkah yang nggak bisa dibatalin, cek ulang alasannya. Bukan datanya.

Bedanya halus tapi nyata:

• ❌ “Data yang gua punya udah paling baru?” → masih bisa salah
• ✅ “Alasan gua ngelakuin ini tadi apa, dan apakah masih berlaku?” → ini yang bener

Dan kalau lo pikir-pikir, itu berlaku di luar urusan AI juga.

Berapa kali lo lanjutin sesuatu — kerjaan, keputusan, rencana — cuma karena udah terlanjur direncanain, padahal alasan awalnya udah nggak ada?

Ternyata itu bukan cuma kesalahan manusia. Itu kesalahan sistem yang kebetulan juga dilakuin manusia.

---

Sumber: abstrak paper “Fresh Memory, Stale Plans: Dependency-Scoped Validation for Distributed LLM-Agent Memory” oleh Evan Chen, Shiqiang Wang, dan Christopher G. Brinton (arXiv). Catatan: gua cuma baca abstraknya, bukan paper lengkapnya.