AI Company · 19 September 2026
Kenapa Agent Lo Jalan di Demo, Mati di Production
Demo 10 menit gampang. Yang susah: agent yang masih hidup di hari ke-30 tanpa lo sentuh. Ini 5 penyebab kematian paling umum, dari sistem yang gue jalanin sendiri.
Semua orang bisa bikin agent yang keren di demo. Lo nulis prompt, agent jawab bagus, lo screenshot, posting "AI is insane 🤯". Selesai.
Terus lo coba jalanin agent itu tiap hari, otomatis, tanpa lo tungguin. Minggu pertama aman. Minggu kedua mulai aneh. Minggu ketiga: mati. Diem-diem pula: gak ada error di muka lo, dia cuma... berhenti kerja, dan lo baru sadar 5 hari kemudian.
Gue jalanin 60+ agent live di Mac mini: content director, daily digest, trading journal, macem-macem. Hampir semua cara mati yang bakal gue ceritain di bawah ini pernah kejadian di sistem gue sendiri. Jadi ini bukan teori. Ini daftar luka.
1. Lo ngetes happy path, production isinya sad path
Di demo, API selalu jawab. Website selalu kebuka. File selalu ada di tempatnya. Di production? API timeout jam 3 pagi. Situs yang lo scrape ganti layout. Rate limit kena pas volume naik.
Agent yang cuma dirancang buat "kalau semua lancar" itu bukan sistem, itu domino yang nunggu disentil. Contoh nyata dari sistem gue: scraper berita yang jalan berbulan-bulan, terus sumbernya ganti struktur halaman. Selector lama masih "jalan", gak error, tapi diam-diam kehilangan 25-30% artikel per section. Gak ada yang crash. Datanya aja yang bolong. Itu jenis kegagalan paling bahaya: yang gak bunyi.
Fix-nya bukan "tulis try-except di mana-mana" doang. Fix-nya: tiap langkah yang nyentuh dunia luar (API, web, file) harus punya jawaban buat tiga pertanyaan. Kalau gagal, ngapain? Kalau hasilnya kosong, itu normal atau alarm? Siapa yang dikabarin?
2. Resource leak: pembunuh yang nyicil
Ini yang paling sering gak kepikiran orang, karena di demo gak pernah muncul. Script yang jalan sekali terus exit? Aman, OS beresin semua. Proses yang hidup terus-terusan? Beda cerita.
Kasus nyata di sistem gue: proses persistent yang buka koneksi SQLite pakai with sqlite3.connect(). Kelihatan bersih kan? Ternyata with di sqlite3 itu cuma nge-commit transaksi, BUKAN nutup koneksi. Tiap loop, satu file descriptor bocor. Proses launchd di macOS default limit-nya 256 FD. Beberapa hari kemudian: unable to open database file. Agent mati, padahal kodenya "gak ada bug" secara logika.
Pelajaran: agent yang hidup 24/7 harus lo pikirin kayak karyawan yang gak boleh nimbun sampah di mejanya. Koneksi ditutup eksplisit. Log di-rotate. Memory dipantau. Sekali jalan beda dengan jalan selamanya.
3. Path dan environment: musuh dalam selimut
Agent lo jalan pas lo test manual dari terminal. Terus lo jadwalin via cron/launchd. Mati. Kenapa? Karena environment scheduler itu BUKAN environment shell lo. PATH-nya beda, env var lo gak kebawa, working directory-nya bukan yang lo kira.
Kejadian nyata: gue pernah mindahin folder project tanpa update file plist launchd yang nunjuk ke path lama. Enam job sekaligus mati diam-diam. Gak ada notifikasi, gak ada error yang muncul di muka. Jobnya cuma gagal start berulang-ulang di background.
Aturan praktis: di script yang dijadwalin, selalu pakai absolute path. Jangan berasumsi env var ada. Load eksplisit dari file config. Dan yang paling penting: kalau lo mindahin sesuatu, cari dulu semua yang nunjuk ke situ sebelum mindahin.
4. Gak ada approval gate = lo percaya 100% ke sistem yang salahnya gak bisa lo prediksi
Agent yang bisa kirim email, posting konten, atau eksekusi transaksi tanpa ada manusia di loop itu bukan otomatisasi, itu judi. LLM itu non-deterministik. Sekali dari seratus dia bakal ngelakuin sesuatu yang bikin lo pengen pindah negara.
Pattern yang gue pakai: approval gate via Discord. Agent nyiapin semuanya: draft konten, rencana aksi, transaksi. Terus berhenti dan nanya. Gue tinggal kasih ✅ atau ❌ dari HP. Content director gue jalan tiap 30 menit nyiapin approval batch; gue yang mutusin mana yang naik.
Kuncinya proporsional: aksi murah dan reversible (nulis draft, baca data) → auto. Aksi mahal atau gak bisa di-undo (publish ke brand utama, kirim email ke orang, transaksi) → wajib lewat gate. Seiring waktu dan track record, gate bisa dilonggarin per-kategori. Tapi mulainya ketat.
5. Gak ada observability: lo gak tau dia mati
Pertanyaan paling penting buat sistem 24/7 bukan "apakah dia jalan?" tapi "kalau dia berhenti, berapa lama sampai gue tau?"
Kebanyakan orang jawabannya: "pas gue kebetulan ngecek." Itu artinya bisa berhari-hari. Daily digest gue pernah gak kekirim dan gue baru ngeh sorenya. Untung cuma digest, bukan sesuatu yang megang duit.
Minimal yang harus ada: (1) log per-run yang bisa dibaca, bukan cuma print ke stdout yang hilang, (2) heartbeat atau notifikasi sukses/gagal ke channel yang lo beneran buka (Discord/Telegram), (3) satu tempat buat liat status semua job sekaligus. Gue akhirnya bikin dashboard fleet sendiri gara-gara capek ngecek job satu-satu.
Benang merahnya
Perhatiin: dari lima penyebab di atas, gak ada satupun yang soal "prompt engineering" atau "model kurang pinter". Semuanya soal sistem di sekeliling model: error handling, resource, environment, kontrol, visibility.
Itu sebabnya gue bilang skill yang langka sekarang bukan "bisa nyuruh AI". Semua orang bisa nyuruh AI. Yang langka: bisa bangun sistem yang bikin AI tetap kerja pas lo tidur, dan bunyi pas ada yang salah.
Demo itu 10% kerjaan. Production itu 90% sisanya, dan justru 90% itu yang bikin agent lo jadi aset, bukan mainan.
Semua pattern di artikel ini: failure handling, scheduling via launchd/cron, approval gate Discord, observability. Gue ajarin build-along di JARVIS Class by INFJ Labs. Bukan dari slide, tapi dari sistem yang beneran jalan.