Pi Durable menyambung kerja agen AI setelah proses terhenti

Agen AI yang berhenti di tengah tugas bisa meninggalkan percakapan, status pekerjaan, dan tindakan di layanan lain dalam keadaan berbeda. Earendil memperkenalkan Pi Durable sebagai paket eksperimental untuk agen yang berjalan lama dan bisa melanjutkan pekerjaan setelah proses mati.

Masalah yang hendak diselesaikan Pi Durable

Menyimpan percakapan saja tidak cukup untuk memulihkan alur kerja agen. Riwayat percakapan menunjukkan pesan, jawaban model, dan hasil alat yang sudah diterima. Riwayat itu belum tentu menunjukkan apakah layanan eksternal sudah membuat sumber daya, mengirim tiket, atau menyelesaikan deployment.

Pi Durable memisahkan percakapan, tugas, dan dokumen aplikasi sebagai keadaan yang perlu dicatat. Agen bisa saja sudah mengirim permintaan ke layanan lain, lalu proses berhenti sebelum hasilnya masuk ke percakapan. Ketika proses dibuka kembali, sistem perlu membedakan tindakan yang belum dimulai, sedang berjalan, selesai tanpa balasan, atau gagal.

Perbedaan itu menentukan cara pemulihan. Percakapan dapat dipakai untuk memahami konteks, checkpoint menunjukkan tahap pekerjaan, sedangkan dokumen aplikasi menyimpan data seperti rencana, tiket, atau daftar pekerjaan. Ketiganya perlu dipantau bersama agar catatan internal tidak menyatakan selesai ketika layanan eksternal masih menunggu.

Kerangka ini menyimpan setiap tahap sebagai tugas dan menulis checkpoint sebelum pekerjaan bergerak ke tahap berikutnya. README resmi menjelaskan bahwa percakapan, giliran model, panggilan alat, dan keadaan aplikasi dikomit ke storage. Mekanisme itu menjaga catatan yang dikelola kerangka, bukan menghapus efek samping di luar kerangka.

Cara pemulihan bekerja setelah proses mati

Ketika proses dibuka kembali dengan storage yang sama, Pi Durable mencari tugas yang belum selesai dan melanjutkannya. Permintaan model yang terputus dikirim lagi, sementara jawaban parsial tetap tercatat sebagai proses yang dibatalkan. Aplikasi harus memastikan proses baru menunjuk ke lokasi data dan versi komponen yang tepat.

Panggilan alat memakai aturan berbeda. Niat menjalankan alat dicatat sebelum fungsi bekerja. Jika proses mati di tengah panggilan, alat dijalankan ulang hanya ketika definisinya menyatakan replay: "safe". Jika tidak, model menerima hasil terputus bersama keluaran yang sempat disimpan.

Penanda aman untuk replay bukan jaminan umum dari framework. Pengembang perlu menilai setiap alat. Membaca berkas atau mencari tiket biasanya lebih mudah diulang daripada mengirim surat elektronik, membuat pembayaran, mengubah catatan pelanggan, atau menjalankan deployment.

Untuk tindakan yang bisa terulang, layanan eksternal perlu memiliki kunci idempoten, pemeriksaan status, atau proses kompensasi. Request ID juga membantu mencegah pengiriman permintaan kerangka yang sama dua kali. Fitur itu tidak membuat pembayaran, pengiriman, dan perubahan data di sistem lain otomatis memiliki jaminan satu kali.

Storage dan batas pemulihan

Dokumentasi Pi Durable mencantumkan Memory, SQLite, dan JSONL. Memory cocok untuk contoh atau pengujian singkat karena isinya hilang ketika proses berakhir. SQLite menyimpan data dalam satu berkas, sedangkan JSONL memakai berkas tambahan yang bersifat append-only.

Pilihan storage mengubah cara tim mengoperasikan layanan. Program yang berpindah container harus tetap menemukan database atau direktori JSONL yang sama. Tim juga perlu menetapkan siapa yang membuka storage dan mencegah dua proses menjalankan tugas yang sama secara bersamaan.

Storage hanya menjaga keadaan yang masuk ke dalamnya. CRM, sistem pembayaran, server surel, repositori kode, dan layanan cloud tetap memiliki keadaan sendiri. Jika tindakan eksternal selesai sebelum hasilnya dikomit, proses pemulihan perlu melakukan pemeriksaan status sebelum memutuskan untuk mengulang.

Perubahan versi juga menjadi bagian dari pemulihan. Tugas lama mungkin merujuk nama ekstensi, bentuk input, atau struktur dokumen yang berbeda dari versi baru. Karena itu, pengujian perlu mencakup migrasi dokumen, perubahan alat, penghentian proses, dan pemulihan setelah deployment.

Kapan agen perlu menjalankan uji Pi Durable?

Pi Durable lebih layak diuji pada pekerjaan yang menunggu persetujuan manusia, menanti API pihak ketiga, berjalan selama berjam-jam, atau melewati beberapa tahap deployment. Biaya mengulang pekerjaan menjadi alasan yang lebih kuat daripada kemungkinan proses berhenti.

Contohnya adalah agen yang mengumpulkan data, membuat draf, menunggu pemeriksaan, lalu memanggil alat untuk memperbarui sistem. Tim bisa mencatat keadaan yang harus kembali tersedia setelah restart, lalu menghentikan proses pada beberapa titik untuk melihat apakah pekerjaan berulang atau tetap konsisten.

Pekerjaan singkat dengan input yang mudah diambil ulang dan tanpa efek samping mahal belum tentu membutuhkan lapisan eksekusi baru. Antrean kerja yang sudah ada mungkin sudah menyimpan status, mencoba ulang, dan menyerahkan pekerjaan ke proses pengganti.

Perbandingan yang tepat bukan antara agen biasa dan Pi Durable sebagai produk yang menang sendiri. Pertanyaannya adalah keadaan apa yang hilang, berapa biaya kehilangan itu, dan siapa yang memeriksa tindakan eksternal setelah pemulihan.

Bagaimana di Indonesia

Tim di Indonesia yang hendak menjalankan agen berjangka panjang perlu memisahkan keputusan teknis dari pertanyaan kepatuhan. Pi Durable adalah komponen untuk menyimpan tugas dan keadaan aplikasi; paket itu tidak menentukan apakah sebuah layanan termasuk Penyelenggara Sistem Elektronik (PSE) Lingkup Privat, data apa yang boleh diproses, atau berapa lama data harus disimpan.

Pemeriksaan awal dapat dimulai dari portal PSE Kementerian Komunikasi dan Digital (Komdigi). FAQ resmi PSE mencantumkan layanan internet, pemrosesan Data Pribadi untuk kegiatan operasional, dan kategori sistem lain yang wajib diperiksa. Daftar itu tidak memberi keputusan otomatis untuk setiap agen. Tim perlu menjelaskan fungsi sistem, pengguna, model bisnis, dan layanan yang dioperasikan.

FAQ yang sama meminta informasi tentang nama sistem, URL, domain atau alamat IP server, model bisnis, fungsi, jenis Data Pribadi yang diproses, serta lokasi pengelolaan, pemrosesan, dan penyimpanan sistem serta Data Elektronik. Daftar ini relevan ketika storage Pi Durable berisi percakapan, dokumen pelanggan, tiket internal, atau hasil panggilan alat. Lokasi berkas SQLite tidak dengan sendirinya menjawab lokasi seluruh alur data, karena model dan layanan pihak ketiga bisa memproses data di tempat lain.

Karena itu, arsitektur untuk tim Indonesia perlu membuat peta data sebelum memilih Memory, SQLite, atau JSONL. Peta tersebut setidaknya mencatat sumber input, data yang masuk ke prompt, dokumen yang ditulis, alat yang dipanggil, penyedia model, lokasi penyimpanan, dan jalur penghapusan. Jika agen menangani data pelanggan atau pegawai, catatan itu membantu tim mengajukan pertanyaan yang tepat kepada penyedia model dan bagian hukum.

Rujukan perlindungan data lokal adalah UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi yang tercatat dalam basis data JDIH BPK. Untuk proyek agen, nama undang-undang itu sebaiknya menjadi awal pemeriksaan, bukan label kepatuhan. Tim masih perlu mengidentifikasi peran para pihak, dasar pemrosesan, hak subjek data, pengamanan, perpindahan data, dan prosedur ketika seseorang meminta koreksi atau penghapusan.

Checkpoint juga menambah pertanyaan retensi. Menghapus tabel utama belum tentu menghapus salinan log, JSONL, backup, cache, atau hasil yang telah dikirim ke alat. Tim perlu menentukan mana yang menjadi catatan operasional, berapa lama setiap catatan diperlukan, siapa yang boleh membacanya, dan bagaimana penghapusan diterapkan pada semua salinan yang berada dalam kendali organisasi.

Kasus penggunaan di Indonesia sebaiknya dimulai dari data yang risikonya terbatas, misalnya pengelompokan tiket internal tanpa nomor identitas atau pencarian dokumentasi teknis yang tidak memuat data pelanggan. Uji berikutnya dapat memasukkan tindakan tulis dengan lingkungan sandbox. Pengiriman notifikasi, perubahan status pesanan, dan pembayaran perlu tetap memiliki pemeriksaan idempoten di sistem tujuan, walaupun alat Pi Durable sudah ditandai aman untuk replay.

Tim juga perlu memeriksa daftar PSE resmi dan meminta penjelasan penyedia tentang pemrosesan data, lokasi layanan, subprosesor, penghapusan, serta notifikasi insiden. Pendaftaran PSE bukan sertifikat bahwa agen aman, dan tidak terdaftar bukan bukti bahwa komponen tertentu otomatis ilegal. Status tersebut adalah satu bagian dari pemeriksaan layanan elektronik yang harus dibaca bersama kontrak dan rancangan teknis.

Harga lokal tidak bisa disimpulkan dari README Pi Durable. Sumber resmi yang diperiksa membahas instalasi paket dan pilihan storage, tetapi tidak menetapkan tarif rupiah, biaya model, biaya server, atau biaya dukungan untuk pengguna Indonesia. Anggaran perlu dihitung dari pemakaian model, penyimpanan, backup, observabilitas, lalu lintas, dan waktu pengembang; angka aktual harus diminta dari penyedia masing-masing.

Pi Durable masih perlu diuji sebagai komponen eksperimental

Pi Durable dapat mengatur checkpoint, percakapan, alat, dan dokumen dalam satu model kerja. Ia tidak menggantikan antrean, transaksi eksternal, kontrol akses, backup, atau prosedur pemulihan organisasi.

Earendil menandai paket ini sebagai eksperimental dan memperingatkan bahwa API bisa berubah antarversi. Karena itu, uji yang berguna harus menghentikan proses di tengah jawaban model, saat alat baca berjalan, setelah tindakan eksternal selesai tetapi sebelum hasil dikomit, dan ketika storage tidak tersedia.

Hasil uji perlu mencatat apakah tugas berulang, apakah keadaan luar dan catatan internal cocok, apakah versi baru bisa membaca tugas lama, serta kapan manusia harus mengambil alih. Jika masalah hanya berada pada percakapan, penyimpanan percakapan mungkin cukup. Jika pekerjaan melewati banyak tahap dan memiliki biaya pengulangan, framework yang menyimpan checkpoint patut dibandingkan dengan sistem yang sudah dipakai.

Kesimpulannya ditentukan oleh keadaan yang harus dikenali setelah pemulihan, bukan oleh lamanya data disimpan. Tim perlu menguji jalur gagal pada beban kerja sendiri sebelum menjadikan Pi Durable bagian dari produksi.

Pertanyaan umum

Apakah Pi Durable sama dengan Pi coding agent?
Bukan. Earendil menjelaskan Pi Durable sebagai harness untuk membangun aplikasi agen, sedangkan Pi coding agent adalah arah produk yang berbeda.

Apakah semua alat otomatis dijalankan ulang?
Tidak. Alat hanya diulang ketika pengembang menyatakannya aman untuk replay. Alat lain dilaporkan sebagai terputus agar model atau aplikasi menentukan langkah berikutnya.

Storage apa yang bisa dipakai?
Dokumentasi mencantumkan Memory, SQLite, dan JSONL. Memory tidak bertahan setelah proses berakhir, sedangkan SQLite dan JSONL bisa dipakai untuk pemulihan lintas proses jika lokasi dan aksesnya dikelola dengan benar.

Apakah Pi Durable sudah menjadi standar produksi?
Belum. Paketnya masih eksperimental, API bisa berubah, dan keandalan serta biaya operasional perlu diuji pada lingkungan yang akan dipakai.