Context vs State vs Memory pada AI Agent: Jangan Dicampur

Context vs State vs Memory pada AI Agent

Sebuah agent sedang menyiapkan laporan bulanan. Ia sudah menarik data iklan, menemukan anomali, dan menunggu konfirmasi finance. Sesi terputus. Saat dibuka lagi, agent membaca seluruh percakapan tetapi mengulang query yang sama dan lupa bahwa approval masih pending. Data ada, chat ada, tetapi posisi kerja hilang. Ini bukan masalah model kurang pintar. Ini masalah arsitektur yang mencampur context, state, dan memory.

Fondasi: definisi kerja yang tidak kabur

Context adalah informasi yang tersedia bagi model pada inferensi sekarang. State adalah posisi workflow saat ini: langkah selesai, hasil tool, artifact, blocker, retry, dan approval. Memory adalah informasi yang dipertahankan untuk dipakai kembali pada sesi atau pekerjaan lain. Ketiganya dapat beririsan, tetapi umur, fungsi, dan cara pengelolaannya berbeda.

Dalam pemisahan context-state, definisi kerja penting karena menentukan ekspektasi. arsitektur yang salah kategori akan diberi tanggung jawab yang salah. Mesin pencari diberi izin menulis ke CRM. Ringkasan chat dianggap state. Preferensi sementara diangkat menjadi policy permanen. Pada skala tim operasional, kekeliruan kecil ini menumpuk menjadi biaya dan risiko.

Komponen yang perlu dibedakan

Context: meja kerja

Instruksi, pesan terbaru, hasil retrieval, dan output tool diletakkan di context window. Kapasitasnya terbatas dan setiap token memakai perhatian model.

State: penanda posisi

State memberi jawaban konkret atas "kita sedang di langkah mana?". Ia harus bisa di-checkpoint dan dipulihkan tanpa memutar ulang semua chat.

Memory: bekal lintas waktu

Memory menyimpan fakta, pengalaman, preferensi, atau prosedur yang layak memengaruhi pekerjaan berikutnya.

Source of truth

CRM, ledger, repository, dan database produksi bukan memory yang boleh dipercaya selamanya. Agent perlu membaca ulang data mutakhir ketika risikonya tinggi.

Contoh bisnis: dari demo ke operasi

Dalam proses invoice, context berisi permintaan user dan data invoice yang sedang diperiksa. State mencatat bahwa validasi pajak selesai, nominal di atas batas, dan approval owner belum masuk. Memory mungkin menyimpan bahwa perusahaan memakai termin 14 hari dan komunikasi finance harus formal. Saldo rekening tetap dibaca dari sistem akuntansi, bukan dari memory bulan lalu.

Dalam pemisahan context-state, perhatikan bahwa nilai tim operasional tidak datang dari jawaban yang terdengar pintar. Nilainya datang dari berkurangnya pekerjaan ulang, handoff yang lebih cepat, keputusan yang dapat ditelusuri, dan aksi yang tidak melampaui izin. Kalau metrik ini tidak berubah, proyek mungkin hanya menambah lapisan antarmuka.

Satu informasi bisa berpindah kategori

Kalimat "diskon disetujui 10%" mula-mula masuk context karena baru disebut finance. Ketika approval dicatat, ia menjadi state untuk proposal yang sedang dikerjakan. Jika angka itu adalah kebijakan akun yang berlaku sampai akhir kuartal, salinan terkurasi dapat dipromosikan menjadi semantic memory dengan sumber, approver, dan tanggal kedaluwarsa. Perpindahan ini harus eksplisit. Menyalin seluruh percakapan ke storage tidak menghasilkan klasifikasi tersebut.

Ada aturan praktis yang lumayan tajam. Jika kehilangan informasi hanya merusak jawaban saat ini, taruh di context. Jika kehilangan informasi membuat pekerjaan diulang atau melompati tahap, simpan sebagai state. Jika informasi berguna lagi pada pekerjaan berbeda, pertimbangkan memory. Untuk saldo, stok, status pembayaran, atau jadwal terkini, tetap baca source of truth saat akan bertindak. Memory boleh membantu menemukan record, bukan menggantikan record.

Saat context terlalu penuh, model tidak otomatis memprioritaskan bagian yang benar. Anthropic menyarankan context engineering sebagai proses memilih kumpulan token terbaik untuk langkah berikutnya, bukan mengumpulkan sebanyak mungkin. Secara operasional, context builder perlu membuang duplikasi, menyertakan sumber, dan menyisakan ruang untuk hasil tool serta instruksi.

Fakta, interpretasi, dan klaim yang harus diuji

Dalam pemisahan context-state, Fakta: request model pada umumnya tidak memperoleh kontinuitas lintas sesi tanpa state yang diteruskan atau disimpan oleh aplikasi. Context window juga memiliki batas, dan informasi yang dimasukkan memakai kapasitas perhatian. Dokumentasi OpenAI tentang conversation state dan panduan Anthropic tentang context engineering menjelaskan konsekuensi desain ini.

Dalam pemisahan context-state, Fakta: framework pelaksana AI modern memisahkan short-term dari long-term ingatan tersimpan. Literatur CoALA juga menawarkan pembagian working, episodic, semantic, dan procedural untuk memahami fungsi ingatan tersimpan. Pembagian tersebut adalah model konseptual, bukan kewajiban memakai vendor atau database tertentu.

Dalam pemisahan context-state, Interpretasi operasional kami: tim operasional sebaiknya menilai second brain dari kemampuan melanjutkan pekerjaan, ketepatan scope, koreksi ingatan tersimpan, dan kontrol aksi. Ini rekomendasi desain, bukan hukum ilmiah. Stack yang tepat tetap bergantung pada risiko, volume, latensi, serta pola query.

Kesalahan implementasi yang mahal

Dalam pemisahan context-state, pertama, menyimpan semua chat. Histori mentah mengandung pengulangan, asumsi, dan keputusan yang sudah berubah. Retrieval kemudian menemukan kalimat yang mirip, bukan yang paling berwenang. Simpan event mentah untuk audit bila memang perlu, tetapi promosikan hanya informasi terpilih menjadi ingatan tersimpan.

Dalam pemisahan context-state, kedua, menjadikan similarity sebagai hakim tunggal. Dua record dapat sangat mirip tetapi berasal dari klien, negara, versi, atau periode berbeda. Filter tenant, hak akses, jenis record, tanggal berlaku, dan authority harus berjalan sebelum atau bersama ranking semantik.

Dalam pemisahan context-state, ketiga, membiarkan ingatan tersimpan menjadi izin. pelaksana AI yang tahu nomor rekening tidak otomatis boleh melakukan transfer. pelaksana AI yang membaca kalender tidak otomatis boleh mengundang pihak luar. Pengetahuan dan authority adalah dua hal terpisah.

Dalam pemisahan context-state, keempat, tidak menyediakan jejak keputusan. Tim perlu melihat input, ingatan tersimpan yang diambil, versi policy, tool call, approval, dan hasil verifikasi. Tanpa itu, debugging berubah menjadi tebak-tebakan.

Checklist implementasi 30 hari

Dalam pemisahan context-state, pada minggu pertama, pilih satu proses dengan histori panjang dan biaya lupa yang nyata. Petakan aktor, sumber data, keputusan, artifact, serta aksi eksternal. Tulis definisi selesai dan daftar risiko. Hindari scope "seluruh perusahaan".

Dalam pemisahan context-state, minggu kedua, buat schema minimum. Setiap ingatan tersimpan setidaknya memiliki owner, scope, tipe, sumber, waktu dibuat, waktu berlaku, confidence, dan status. State pekerjaan memiliki ID, langkah aktif, artifact, blocker, retry, serta approval pending.

Dalam pemisahan context-state, minggu ketiga, pasang retrieval dan guardrail. Terapkan namespace, access control, metadata filtering, serta ranking. Batasi tool ke operasi read atau draft. Untuk write eksternal, destructive, finansial, dan sensitif, gunakan approval eksplisit.

Dalam pemisahan context-state, minggu keempat, jalankan kasus nyata dan kasus jebakan. Masukkan record lama, dua klien dengan istilah serupa, fakta yang dikoreksi, pekerjaan yang terputus, dan input yang mencoba mengubah policy. Ukur bukan hanya kualitas jawaban, tetapi juga apakah pelaksana AI berhenti ketika ragu.

Pertanyaan audit untuk tim

• Informasi apa yang dipakai agent, dan dari sumber mana?
• Apakah scope user, organisasi, dan klien diterapkan sebelum retrieval?
• Bagaimana fakta lama diganti, dikoreksi, atau dihapus?
• Bisakah task dilanjutkan tanpa mengulang action yang sudah sukses?
• Action mana yang otomatis, mana yang wajib approval?
• Apakah hasil tool diverifikasi dari environment?
• Siapa yang dapat membaca audit log dan mengubah policy?

Dalam pemisahan context-state, jawaban "belum tahu" bukan bencana. Itu tanda bahwa arsitektur belum pantas diberi otonomi lebih luas.

Cara menerapkannya tanpa proyek raksasa

Desain praktisnya: beri setiap elemen TTL dan pemilik. Context boleh dibuang setelah run. State disimpan per task dan diubah lewat transisi yang jelas. Memory diberi scope, provenance, confidence, dan mekanisme koreksi. Data volatil selalu diverifikasi ke sumber utama. Jangan memasukkan seluruh histori hanya karena context window muat.

Dalam pemisahan context-state, mulai dengan baseline manual. Catat berapa lama orang mencari konteks, berapa pekerjaan yang diulang, berapa koreksi akibat data lama, dan berapa approval terlambat. Setelah pelaksana AI berjalan, bandingkan angka yang sama. Ukuran seperti jumlah record terindeks atau banyaknya token bukan hasil tim operasional.

Desain checkpoint yang bisa dipulihkan

Checkpoint yang baik bukan dump seluruh runtime. Ia memuat task ID, tujuan, langkah aktif, input yang sudah divalidasi, artifact yang dihasilkan, tool call beserta idempotency key, blocker, dan approval yang masih berlaku. Simpan juga versi workflow. Tanpa versi, task lama yang dipulihkan setelah prosedur berubah dapat masuk ke langkah yang salah.

Pemulihan perlu dites seperti backup. Putuskan proses tepat setelah tool eksternal dipanggil tetapi sebelum respons tercatat. Saat hidup kembali, agent harus memeriksa lingkungan lebih dulu: apakah invoice sudah dibuat, email sudah terkirim, atau budget sudah berubah? Jika langsung mengulang, efek samping dapat terjadi dua kali. Untuk operasi yang mendukung idempotency key, gunakan fasilitas itu; untuk yang tidak, sediakan reconciliation.

Context baru kemudian dirakit dari checkpoint, instruksi aktif, dan memory yang relevan. Tidak perlu menghidupkan kembali semua percakapan. Ringkasan keputusan, tautan artifact, dan beberapa pesan terakhir biasanya lebih bersih. Ukur keberhasilannya dengan recovery rate, action ganda, token per langkah, dan berapa kali operator harus menjelaskan ulang posisi pekerjaan.

Kesimpulan praktis

Kalau agent pelupa, jangan langsung menambah token atau vector database. Tanyakan dulu: informasi ini dibutuhkan sekarang, untuk melanjutkan task, atau untuk dipakai lintas task? Jawaban itu menentukan apakah ia context, state, atau memory. Pemisahan sederhana ini menghemat biaya sekaligus membuat kegagalan lebih mudah dilacak.

Referensi primer

• Anthropic -- Effective Context Engineering for AI Agents
• Anthropic -- Building Effective AI Agents
• OpenAI API -- Conversation State
• LangGraph -- Memory Overview
• Model Context Protocol -- Introduction
• CoALA -- Cognitive Architectures for Language Agents

---

Dalam pemisahan context-state, ← Artikel sebelumnya · Hub Second Brain · Artikel berikutnya →