AWS AgentCore Runtime Instances: AI Agent Bisa Berjalan hingga 14 Hari
AWS mengumumkan AgentCore Runtime Instances tersedia umum. Fitur ini membuka opsi menjalankan AI agent di instance EC2 milik pengguna untuk sesi hingga 14 hari, berbeda dari runtime serverless microVM yang cocok untuk sesi hingga 8 jam.
AWS AgentCore Runtime Instances: AI Agent Bisa Berjalan hingga 14 Hari
Automation yang berjalan berjam-jam atau berhari-hari tidak bisa lagi diperlakukan seperti script sekali jalan. Untuk owner bisnis, ini berarti AI agent yang mengurus approval, follow-up, analisis dokumen, atau orkestrasi workflow lintas sistem harus diperlakukan seperti service production: ada monitoring, audit log, recovery, batas biaya, dan mekanisme untuk menghentikannya saat ada masalah.
Pada 6 Agustus 2026, AWS mengumumkan bahwa AgentCore runtime instances sudah tersedia umum. Berdasarkan pengumuman tersebut, agent kini dapat berjalan pada instance EC2 milik pengguna, dengan dukungan sesi jangka panjang hingga 14 hari. AWS juga tetap menyediakan runtime serverless berbasis microVM untuk sesi sampai 8 jam.
Bagi programmer, Head of Software Engineering, manager SDLC, dan calon CTO, perubahan ini penting bukan karena semua agent harus berjalan lama. Justru sebaliknya, ini memaksa kita membedakan mana job yang memang short-lived dan mana workflow yang benar-benar long-running.
Fakta Utama dari Pengumuman AWS
Dari informasi yang diumumkan AWS, ada beberapa poin yang perlu dicatat:
- AgentCore runtime instances sudah generally available.
- AI agent dapat berjalan pada instance EC2 milik pengguna.
- Sesi agent jangka panjang dapat berjalan hingga 14 hari.
- Runtime serverless microVM tetap tersedia untuk sesi sampai 8 jam.
Saya sengaja memisahkan fakta ini dari interpretasi teknis di bawah. Detail desain, biaya, kapasitas, dan governance tetap perlu divalidasi langsung di dokumentasi dan konfigurasi AWS yang digunakan tim Anda.
Short-Lived Job vs Long-Running Workflow
Untuk banyak use case, runtime serverless microVM sampai 8 jam sudah cukup. Misalnya:
- Menjawab pertanyaan pengguna.
- Menjalankan task analisis singkat.
- Membuat ringkasan dokumen.
- Mengorkestrasi beberapa API call yang durasinya masih terukur.
- Menjalankan job batch kecil yang tidak membutuhkan state panjang.
Namun ada jenis automation yang durasinya tidak natural jika dipaksa selesai cepat. Contohnya workflow yang menunggu approval manusia, memproses banyak tahap review, berinteraksi dengan sistem eksternal yang lambat, atau melakukan iterasi perbaikan selama beberapa hari.
Di sinilah runtime instance menjadi menarik. Bukan karena long-running selalu lebih baik, tetapi karena ada kelas masalah yang memang membutuhkan eksekusi lebih panjang dan kontrol lingkungan yang lebih dekat dengan model service production.
Persistence: Jangan Mengandalkan Memori Proses
Sesi hingga 14 hari bukan alasan untuk menyimpan state penting hanya di memory. Instance bisa bermasalah, proses bisa restart, deployment bisa terjadi, dan network dependency bisa gagal.
Untuk workflow panjang, saya akan tetap mendesain persistence secara eksplisit. Status agent, langkah yang sudah selesai, input penting, output per tahap, dan keputusan manusia sebaiknya disimpan di storage yang tahan restart. Dengan begitu, agent tidak menjadi kotak hitam yang sulit dijelaskan ketika ada incident.
Prinsip praktisnya sederhana: jika workflow tidak boleh hilang, state-nya juga tidak boleh hanya hidup di RAM.
Checkpoint dan Recovery Harus Jadi Desain Awal
Long-running workflow perlu checkpoint. Setiap tahap penting sebaiknya punya titik simpan yang jelas, misalnya setelah dokumen berhasil diproses, setelah approval diterima, atau setelah perubahan dikirim ke sistem eksternal.
Tanpa checkpoint, recovery akan mahal. Ketika agent gagal di hari ketiga, tim bisa terpaksa mengulang proses dari awal atau melakukan manual repair yang rawan error.
Untuk tim SDLC, saya menyarankan workflow agent diperlakukan seperti state machine: ada status, transisi, retry policy, dan catatan kenapa sebuah langkah dianggap berhasil atau gagal.
Idempotency: Kunci agar Retry Tidak Merusak Data
Agent yang berjalan lama hampir pasti akan menghadapi retry. API timeout, koneksi putus, rate limit, atau dependency eksternal lambat adalah hal normal.
Masalahnya, retry tanpa idempotency bisa berbahaya. Contoh sederhana: agent mengirim approval dua kali, membuat tiket duplikat, atau menjalankan perubahan konfigurasi berulang.
Untuk workflow production, setiap aksi penting perlu idempotency key atau mekanisme deduplikasi. Tujuannya bukan hanya agar sistem lebih rapi, tetapi agar kegagalan parsial tidak berubah menjadi kerusakan data.
Timeout Tidak Hilang, Hanya Berubah Level
Sesi hingga 14 hari bukan berarti timeout tidak relevan. Timeout tetap perlu ada, hanya levelnya berubah.
Pada short-lived job, timeout biasanya bicara menit atau jam. Pada long-running workflow, timeout bisa berupa batas waktu menunggu approval, batas waktu menunggu respons sistem eksternal, atau batas maksimal sebuah tahap boleh berjalan.
Saya akan menghindari workflow tanpa batas waktu. Jika suatu tahap menunggu terlalu lama, sistem harus punya keputusan: retry, eskalasi, minta intervensi manusia, atau hentikan proses.
Patching dan Maintenance: Instance Berarti Tanggung Jawab Operasional
Karena AgentCore runtime instances berjalan pada instance EC2 milik pengguna, tim perlu berpikir tentang tanggung jawab operasional yang menyertainya. Ini berbeda nuansanya dengan model serverless microVM yang lebih cocok untuk pekerjaan pendek.
Untuk long-running agent, pertanyaan yang harus dijawab sejak awal antara lain:
- Bagaimana strategi patching instance?
- Kapan aman melakukan restart?
- Apakah workflow bisa resume setelah maintenance?
- Bagaimana memastikan dependency agent tetap kompatibel?
- Siapa yang bertanggung jawab ketika runtime sehat tetapi workflow macet?
Di sinilah AI automation mulai mirip dengan service backend biasa. Bedanya, agent sering mengambil keputusan bertahap, sehingga observability dan audit trail menjadi lebih penting.
Capacity dan Cost Idle Perlu Dihitung
Runtime instance memberi ruang untuk sesi lebih panjang, tetapi kapasitas dan biaya idle perlu diperhatikan. Jika agent menunggu approval selama berhari-hari, apakah instance tetap aktif? Apakah kapasitasnya dipakai efisien? Berapa banyak workflow paralel yang akan berjalan?
Saya tidak akan langsung memindahkan semua agent ke runtime instance. Untuk task singkat, serverless microVM sampai 8 jam tetap bisa menjadi opsi yang lebih sederhana. Runtime instance lebih masuk akal ketika durasi, kontrol, dan kebutuhan recovery membenarkan kompleksitas tambahannya.
Keputusan arsitektur sebaiknya berbasis profil workload, bukan sekadar fitur baru.
Approval, Audit Log, dan Kill Switch
Semakin lama agent berjalan, semakin besar kebutuhan governance. Untuk use case bisnis yang sensitif, agent sebaiknya tidak dibiarkan melakukan semua aksi tanpa batas.
Beberapa kontrol yang saya anggap wajib untuk long-running workflow:
- Approval manusia untuk aksi berisiko tinggi.
- Audit log untuk input, keputusan, tool call, dan output penting.
- Kill switch untuk menghentikan workflow bermasalah.
- Batas biaya atau batas jumlah aksi.
- Mekanisme eskalasi jika agent tidak yakin atau mendeteksi anomali.
Kill switch sering dilupakan karena tim terlalu fokus pada demo. Padahal dalam production, kemampuan menghentikan automation sama pentingnya dengan kemampuan menjalankannya.
Dampaknya untuk Tim Engineering dan SDLC
Bagi tim engineering, pengumuman ini adalah sinyal bahwa AI agent makin mendekati pola kerja service production. Artinya proses SDLC juga perlu ikut berubah.
Agent yang berjalan lama perlu masuk ke checklist desain arsitektur, threat modeling, observability, deployment plan, dan incident response. QA tidak cukup hanya menguji apakah prompt menghasilkan jawaban bagus. Tim juga perlu menguji skenario gagal, restart, retry, approval terlambat, dependency down, dan data parsial.
Untuk manager SDLC dan calon CTO, pertanyaan strategisnya bukan apakah kita bisa membuat agent berjalan 14 hari. Pertanyaan yang lebih penting adalah apakah organisasi siap mengoperasikan automation selama 14 hari dengan aman, terukur, dan bisa diaudit.
Rekomendasi Praktis
Jika tim Anda sedang mengevaluasi AgentCore runtime instances, saya akan mulai dari langkah berikut:
- Klasifikasikan workflow menjadi short-lived job dan long-running workflow.
- Gunakan runtime pendek untuk task yang selesai dalam batas waktu wajar dan tidak butuh state panjang.
- Pertimbangkan runtime instance untuk workflow yang memang membutuhkan sesi panjang, kontrol environment, dan recovery yang matang.
- Desain persistence, checkpoint, idempotency, dan audit log sejak awal.
- Tetapkan timeout, approval, cost guardrail, dan kill switch sebelum masuk production.
- Uji skenario recovery, bukan hanya happy path.
Dengan pendekatan ini, tim tidak terjebak menggunakan runtime instance hanya karena fiturnya baru. Teknologi yang tepat adalah teknologi yang sesuai dengan risiko dan bentuk workload.
Penutup
AgentCore runtime instances membuat opsi arsitektur AI agent di AWS menjadi lebih luas. Sesi hingga 14 hari membuka peluang untuk automation yang lebih panjang dan kompleks, sementara runtime serverless microVM tetap relevan untuk pekerjaan singkat sampai 8 jam.
Bagi saya, pelajaran utamanya jelas: semakin lama agent berjalan, semakin ia harus diperlakukan seperti sistem production. Persistence, checkpoint, idempotency, recovery, patching, capacity, cost idle, approval, audit log, dan kill switch bukan tambahan belakangan. Semuanya adalah bagian dari desain.
Tidak semua agent membutuhkan instance persisten. Tetapi untuk workflow yang berjalan berjam-jam atau berhari-hari, pendekatan production-grade bukan lagi pilihan nice to have, melainkan kebutuhan dasar.