Kenapa AI Anda Tiba-Tiba 'Bego' di Tengah Percakapan Panjang?
Pernah mengalami ini: di awal sesi, AI Anda cerdas, presisi, dan mengikuti instruksi dengan baik. Tapi setelah puluhan pesan, membaca banyak file, dan menjalankan banyak tool call, jawabannya mulai ngawur. Ia lupa keputusan yang sudah disepakati, mengulangi pertanyaan yang sudah dijawab, atau salah mengutip detail teknis yang sebenarnya sudah ada di percakapan.
Ini bukan bug, dan bukan tanda model-nya "bodoh". Ini adalah konsekuensi langsung dari cara kerja context window—dan memahami mekanismenya adalah langkah pertama sebelum Anda bisa memperbaikinya.
Context Window Itu Sumber Daya Terbatas, Bukan Ruang Kosong Gratis
Banyak developer memperlakukan context window seperti hard disk: selama belum penuh, isi saja terus—riwayat percakapan, hasil pencarian, isi dokumen, log tool call. Anggapannya, selama belum mentok limit token, semuanya aman.
Asumsi ini keliru. Context adalah kumpulan token yang harus diproses model setiap kali ia melakukan inferensi, dan setiap token yang masuk memakan "anggaran perhatian" (attention budget) yang sifatnya terbatas. Ini berakar dari arsitektur transformer itu sendiri: setiap token bisa saling berelasi dengan setiap token lain dalam context, sehingga jumlah relasi ini tumbuh secara kuadratik (n²) seiring bertambahnya token. Semakin panjang context, semakin "encer" kemampuan model untuk menangkap semua relasi itu secara presisi.
Analoginya mirip working memory manusia: kita punya kapasitas terbatas untuk menahan informasi aktif di kepala. Menjejalkan lebih banyak data ke context window tidak membuat model makin pintar—justru sebaliknya, ia harus berbagi "perhatian" ke lebih banyak hal sekaligus.
Prinsip context engineering yang baik sebenarnya sederhana: cari kumpulan token seminimal mungkin yang paling bersinyal tinggi (high-signal) untuk mencapai hasil yang diinginkan. Bukan soal seberapa besar context window yang tersedia, tapi seberapa efisien Anda mengisinya.
Context Rot: Kenapa Akurasi Turun Saat Window Makin Penuh
Fenomena ini punya nama teknis: context rot. Riset benchmarking gaya "needle-in-a-haystack" menemukan pola yang konsisten di berbagai model: semakin banyak token dalam context window, semakin menurun kemampuan model untuk mengambil kembali (recall) informasi dari context tersebut secara akurat—meski informasi itu secara teknis masih ada di sana.
Yang penting dipahami: ini bukan tebing curam (hard cliff), melainkan gradien performa yang menurun perlahan. Model tetap cukup mampu di context panjang, tapi presisi retrieval dan reasoning jarak jauhnya berkurang dibanding saat context masih pendek. Sebagian model mendegradasi lebih halus dari yang lain, tapi karakteristik ini muncul di semua model.
Contoh nyata dari eksperimen dengan agent riset: ketika agent membaca delapan dokumen berukuran sekitar 40.000 token masing-masing tanpa manajemen context sama sekali, context window-nya membengkak hingga lebih dari 300.000 token. Breakdown isi context menunjukkan lebih dari 96% dari seluruh token itu adalah hasil pembacaan file—kebanyakan dokumen yang sudah dibaca dan dicatat sebelumnya, tapi tetap ikut diproses ulang di setiap giliran, bersaing memperebutkan perhatian model dengan informasi yang lebih relevan.
Ada dua konsekuensi praktis dari context rot:
- Pada model dengan window terbatas (misalnya 200K token), agent akan berhenti total begitu limit tercapai—API menolak permintaan berikutnya dan tugas terhenti di tengah jalan.
- Pada model dengan window besar (misalnya 1 juta token), agent tetap bisa jalan terus, tapi kualitas jawabannya menurun karena detail-detail awal "tenggelam" di bawah tumpukan informasi yang terus bertambah.
Jadi menunggu context window yang lebih besar bukan solusi jangka panjang—context tetap akan penuh dengan data yang sudah tidak relevan, hanya saja dinding batasnya lebih jauh.
Tiga Primitif Utama untuk Mengelola Context
Ada tiga teknik inti yang saling melengkapi untuk menjaga context tetap ramping pada tugas-tugas panjang:
1. Compaction (Peringkasan Otomatis)
Compaction adalah praktik mengambil percakapan yang sudah mendekati batas context window, meringkasnya, lalu memulai ulang context baru dengan ringkasan tersebut sebagai fondasi. Model diminta menyaring detail penting—keputusan arsitektur, bug yang belum terselesaikan, langkah selanjutnya—sambil membuang hasil tool call yang redundan atau pesan yang sudah tidak relevan.
Dalam pengujian, ketika trigger compaction diset pada ambang tertentu, sebuah percakapan riset yang tadinya bisa membengkak sampai 335.000 token berhasil ditekan puncaknya ke sekitar 169.000 token setelah ringkasan otomatis diterapkan. Fakta-fakta level tinggi (seperti nama organisme dan angka umur) cenderung bertahan dalam ringkasan, sementara detail sangat spesifik (misalnya satu angka di tabel lampiran) biasanya hilang.
Seninya ada pada apa yang dipertahankan versus dibuang. Compaction yang terlalu agresif bisa menghilangkan konteks halus namun krusial yang baru terasa penting belakangan. Karena itu, instruksi peringkasan sebaiknya disesuaikan—misalnya secara eksplisit meminta model mempertahankan angka kuantitatif tertentu beserta sumbernya.
2. Structured Note-Taking (Memory File)
Teknik ini disebut juga agentic memory: agent secara rutin menulis catatan ke penyimpanan persisten di luar context window, lalu menarik kembali catatan itu saat dibutuhkan di sesi berikutnya. Ini mirip cara Claude Code mempertahankan to-do list, atau agent kustom yang menjaga file semacam NOTES.md.
Manfaatnya terlihat jelas pada tugas lintas sesi. Dalam sebuah eksperimen, sesi kedua yang tidak punya akses ke memory harus membaca ulang seluruh delapan dokumen sumber (memuncak di 333.977 token). Sedangkan sesi kedua yang bisa membaca catatan dari sesi pertama hanya perlu membaca empat dokumen baru dan cukup mengandalkan memory untuk sisanya—konteks puncaknya turun ke sekitar 172.623 token, dengan empat kali lebih sedikit pembacaan file.
Kuncinya: memory memberi fidelitas lossless untuk apa pun yang dipilih agent untuk disimpan, tapi kualitasnya sepenuhnya bergantung pada seberapa baik penilaian agent tentang apa yang layak dicatat. Memory yang berantakan atau terlalu sedikit tidak akan banyak membantu.
3. Tool Result Clearing
Setiap kali agent memanggil tool—membaca file, memanggil API, melakukan pencarian—hasilnya ikut menumpuk di riwayat percakapan dan terus dihitung dalam anggaran token di setiap giliran berikutnya, meskipun model sudah memprosesnya dan berpindah ke topik lain.
Tool result clearing mengganti hasil tool call lama dengan placeholder singkat, sambil tetap mempertahankan catatan bahwa panggilan tool itu pernah terjadi (nama tool dan inputnya). Jika agent butuh data itu lagi, ia tinggal memanggil tool tersebut ulang. Ini adalah teknik paling murah dari ketiganya karena tidak memerlukan inferensi tambahan—hanya operasi mekanis pada daftar pesan.
Dalam pengujian, sebuah sesi yang tanpa manajemen context memuncak di 335.279 token, sementara sesi dengan clearing aktif tertahan di sekitar 173.137 token meski jumlah file yang dibaca sama. Trade-off-nya: hasil tool call lama benar-benar hilang dari context sampai dipanggil ulang, jadi teknik ini paling cocok untuk hasil yang murah untuk diambil ulang (seperti membaca file lokal), dan kurang cocok untuk API yang lambat atau memiliki rate limit ketat.
Sub-Agent: Memisahkan Context Window untuk Tugas Panjang
Selain tiga primitif di atas, ada pendekatan arsitektural: sub-agent. Alih-alih satu agent mencoba mempertahankan seluruh state proyek dalam satu context window, sub-agent khusus menangani tugas-tugas fokus dengan context window-nya sendiri yang bersih.
Agent utama (lead agent) bertindak sebagai koordinator dengan rencana level tinggi, sementara sub-agent melakukan eksplorasi mendalam—bisa menghabiskan puluhan ribu token atau lebih—namun hanya mengembalikan ringkasan terkondensasi (biasanya 1.000–2.000 token) ke agent utama. Hasilnya adalah pemisahan tanggung jawab yang jelas: context pencarian yang detail tetap terisolasi di dalam sub-agent, sementara agent utama fokus mensintesis dan menganalisis hasil akhirnya. Pendekatan ini terbukti memberi peningkatan signifikan dibanding sistem satu-agent pada tugas riset kompleks.
Pendekatan sub-agent ini juga relevan untuk tugas yang berjalan lintas banyak sesi—misalnya proyek coding yang berlangsung berjam-jam bahkan berhari-hari. Dalam eksperimen membangun aplikasi web kompleks lintas banyak context window, pola kegagalan yang sering muncul adalah: agent mencoba menyelesaikan semuanya sekaligus (one-shot) hingga kehabisan context di tengah implementasi, atau sebaliknya, agent di sesi berikutnya melihat progres yang sudah ada lalu menyimpulkan pekerjaannya sudah selesai—padahal belum.
Solusinya adalah struktur dua peran: initializer agent yang menyiapkan lingkungan kerja di sesi pertama (skrip setup, daftar fitur terstruktur dalam format JSON, commit git awal), dan coding agent di setiap sesi berikutnya yang diminta mengerjakan satu fitur pada satu waktu, lalu meninggalkan jejak yang jelas—commit git dengan pesan deskriptif dan file catatan progres—sebelum sesi berakhir. Dengan begitu, sesi baru bisa langsung membaca log git dan file progres untuk memahami kondisi terkini tanpa harus menebak-nebak apa yang terjadi sebelumnya.
Cara Mendiagnosis Masalah Context Anda Sebelum Memilih Solusi
Kesalahan umum adalah langsung menerapkan semua teknik di atas sekaligus tanpa tahu masalah sebenarnya. Padahal setiap primitif menyasar jenis pertumbuhan context yang berbeda. Berikut cara mendiagnosisnya:
| Gejala yang Anda Amati | Kemungkinan Penyebab | Primitif yang Paling Cocok |
|---|---|---|
| Percakapan panjang, banyak dialog bolak-balik dan reasoning | Pertumbuhan context dari seluruh transkrip | Compaction |
| Context didominasi hasil pembacaan file/API yang besar dan bisa diambil ulang | Bloat dari hasil tool call | Tool Result Clearing |
| Pekerjaan berlangsung lintas sesi/hari, butuh melanjutkan dari titik terakhir | Tidak ada persistensi lintas sesi | Structured Note-Taking (Memory) |
| Tugas riset atau eksplorasi mendalam yang butuh menjelajah banyak sumber | Context tercampur antara eksplorasi detail dan sintesis | Sub-agent Architecture |
Beberapa pertanyaan praktis yang bisa Anda ajukan pada workload Anda sendiri:
- Apakah sesi Anda cukup pendek sehingga tidak pernah mendekati limit context secara alami? Jika ya, Anda mungkin tidak butuh compaction sama sekali—teknik ini bersifat lossy (detail spesifik hilang saat diringkas), jadi jangan membayar fidelitas untuk sesuatu yang tidak Anda butuhkan.
- Apakah agent Anda benar-benar perlu melihat kembali hasil tool call lama secara utuh? Jika agent melakukan analisis lintas dokumen yang membandingkan potongan teks secara berdampingan, clearing bisa memaksa pembacaan ulang yang berlebihan dan justru kontraproduktif.
- Apakah setiap sesi memang seharusnya dimulai dari nol? Untuk chatbot yang setiap percakapannya independen, menambahkan memory justru membawa state yang tidak Anda inginkan.
Setelah tahu jenis masalahnya, langkah berikutnya adalah menguji konfigurasi (ambang trigger, jumlah yang dipertahankan, instruksi peringkasan) langsung terhadap workload nyata Anda—bukan asumsi generik. Data seperti jumlah token yang berhasil dibebaskan atau apa yang bertahan dalam ringkasan bisa diamati langsung dan dijadikan dasar penyesuaian.
Penutup
Context engineering pada dasarnya adalah pergeseran cara berpikir: dari sekadar menulis prompt yang bagus, menjadi mengelola dengan cermat token apa saja yang berhak masuk ke "anggaran perhatian" model di setiap langkah. Tidak semua workload butuh compaction, memory, dan clearing sekaligus—pertanyaan yang lebih tepat bukan "haruskah saya pakai ketiganya?", melainkan "masalah context mana yang sebenarnya dialami workload saya?"
Jika Anda membangun aplikasi, otomasi, atau layanan berbasis AI agent yang mulai terasa "lupa" atau melambat seiring bertambahnya kompleksitas tugas, langkah pertama yang paling murah adalah mendiagnosis dulu, baru memilih teknik yang tepat—bukan menumpuk semua solusi sekaligus.
Referensi
- Anthropic Engineering, "Effective context engineering for AI agents"
- Claude Cookbook, "Context engineering: memory, compaction, and tool clearing"
- Anthropic Engineering, "Effective harnesses for long-running agents"
