Mengapa Context Window Selalu Jadi Masalah
Setiap engineer yang pernah menjalankan AI agent untuk tugas yang berlangsung lama—migrasi codebase besar, riset multi-dokumen, atau proyek yang berjalan lintas beberapa sesi—pasti pernah menabrak dinding yang sama: context window yang penuh. Masalahnya bukan cuma soal kapasitas token. Riset tentang context rot menunjukkan bahwa semakin banyak token yang menumpuk di context window, semakin menurun kemampuan model untuk mengingat informasi secara akurat dari dalamnya, bahkan sebelum batas token keras tercapai. Attention model itu seperti anggaran yang terbatas, dan setiap token baru yang masuk mengurangi anggaran tersebut.
Untuk agent yang berjalan dalam loop—membaca dokumen, memanggil tool, menulis catatan—volume data yang berpotensi relevan terus bertambah di setiap giliran. Di sinilah context engineering masuk: bukan sekadar menulis prompt yang bagus, tapi secara aktif mengelola set token apa saja yang boleh masuk ke context window pada setiap langkah.
Artikel ini membahas empat primitif praktis yang digunakan untuk menangani masalah ini pada tugas long-horizon, plus cara mendiagnosis primitif mana yang sebenarnya dibutuhkan workload Anda.
1. Compaction: Meringkas Sesi Sebelum Window Berikutnya Dimulai
Compaction adalah praktik mengambil percakapan yang mendekati batas context window, meringkas isinya, lalu memulai window baru dengan ringkasan tersebut sebagai dasar. Ini adalah operasi whole-transcript: pesan user, respons assistant, pemanggilan tool, hasil tool, bahkan ringkasan compaction sebelumnya—semuanya diratakan menjadi satu ringkasan padat.
Inti dari compaction terletak pada seleksi: apa yang dipertahankan versus apa yang dibuang. Compaction yang terlalu agresif bisa menghilangkan detail halus namun krusial yang baru terasa pentingnya belakangan. Pada implementasi Claude Code misalnya, model mempertahankan keputusan arsitektural, bug yang belum terselesaikan, dan detail implementasi, sementara hasil tool yang redundan dibuang.
Dari eksperimen menggunakan agent riset yang membaca delapan dokumen ulasan ilmiah (~320 ribu token total), compaction berhasil menekan puncak konteks dari sekitar 335 ribu token menjadi sekitar 169 ribu token. Pengujian terhadap ringkasan yang dihasilkan menunjukkan pola yang konsisten: fakta tingkat tinggi yang sentral bagi tugas—seperti angka masa hidup organisme atau kesimpulan komparatif utama—cenderung bertahan dalam ringkasan, sementara detail obscure seperti nilai statistik di tabel lampiran biasanya hilang.
Yang perlu dipahami: instruksi kustom untuk compaction (instructions) menggantikan prompt ringkasan default sepenuhnya, bukan menambahinya. Jadi jika Anda menulis instruksi sendiri, Anda bertanggung jawab penuh atas framing-nya—misalnya secara eksplisit meminta model mempertahankan setiap angka kuantitatif beserta sumbernya.
2. Structured Note-Taking: Menulis State yang Bertahan di Luar Context Window
Structured note-taking, atau memory agentik, adalah teknik di mana agent secara rutin menulis catatan yang disimpan secara persisten di luar context window, lalu menariknya kembali saat dibutuhkan. Ini memberikan memori persisten dengan overhead minimal—mirip seperti Claude Code yang membuat to-do list, atau agent kustom yang menjaga file NOTES.md.
Berbeda dari compaction dan tool clearing yang beroperasi pada window yang sedang aktif, memory menyelesaikan masalah lintas sesi. Saat sesi baru dimulai dengan context window kosong, compaction dan clearing tidak banyak membantu—memory-lah yang menjembatani kesenjangan itu.
Dalam pengujian dua sesi pada agent riset yang sama: Sesi 2 tanpa akses ke memory harus membaca ulang semua delapan dokumen sumber dari nol, mencapai puncak konteks sekitar 334 ribu token. Sesi 2 dengan akses ke catatan Sesi 1 hanya perlu membaca empat dokumen yang belum tercakup, karena ia langsung menarik temuan komparatif dari file memory yang sudah ada—puncak konteksnya turun menjadi sekitar 173 ribu token dengan empat kali lebih sedikit pemanggilan baca file.
Kualitas hasil memory sangat bergantung pada penilaian agent tentang apa yang layak disimpan. Beberapa strategi yang terbukti membantu: memberi instruksi topikal eksplisit tentang jenis informasi apa yang harus dicatat, meminta agent menjaga direktori memory tetap rapi dan terorganisir (mengganti nama atau menghapus file yang sudah tidak relevan), serta menjalankan sesi inisialisasi khusus di awal proyek multi-sesi untuk menyiapkan struktur artefak memory sebelum pekerjaan substantif dimulai.
3. Tool Result Clearing: Membuang Observasi Basi Tanpa Kehilangan Jejak Reasoning
Setiap kali agent memanggil tool, hasilnya ditambahkan ke riwayat percakapan sebagai blok tool_result. Blok ini terus membebani anggaran token pada setiap giliran berikutnya, meskipun agent sudah memproses isinya dan melangkah maju. Untuk tool yang bisa dipanggil ulang—pembacaan file, query API, pencarian—membawa hasil verbatim tersebut ke depan seringkali tidak perlu.
Tool result clearing mengganti blok tool_result lama dengan placeholder singkat, sementara blok tool_use yang mendahuluinya tetap dipertahankan. Artinya model masih tahu bahwa ia pernah memanggil tool tersebut dan dengan input apa, tapi payload besarnya sudah hilang. Ini adalah operasi sub-transcript—hanya menyentuh hasil tool, tidak menyentuh pesan user, reasoning assistant, atau catatan pemanggilan tool itu sendiri.
Ini adalah bentuk kompaksi konteks paling ringan dan paling aman: tidak ada biaya inferensi tambahan, hanya penyuntingan mekanis terhadap daftar pesan. Pada pengujian, clearing berhasil menahan puncak konteks di sekitar 173 ribu token dibanding baseline yang mencapai 335 ribu token, dengan empat kali proses clearing yang masing-masing membebaskan sekitar 160 ribu token.
Konsekuensinya: hasil baca file yang lebih lama benar-benar hilang dari konteks. Jika agent membutuhkannya lagi, ia harus memanggil tool tersebut ulang—murah untuk pembacaan file lokal, tapi bisa mahal untuk API yang lambat atau dibatasi rate limit. Satu hal teknis penting: clearing membatalkan validitas cache prefix prompt, sehingga parameter clear_at_least perlu diatur agar jumlah token yang dibersihkan cukup besar supaya invalidasi cache itu sepadan.
4. Initializer Agent Plus Incremental Worker: Pola Harness untuk Agent yang Berjalan Lama
Untuk tugas yang membentang berjam-jam bahkan berhari-hari melewati banyak context window, compaction saja ternyata tidak cukup. Eksperimen membangun aplikasi web skala produksi menggunakan agent coding menunjukkan dua pola kegagalan yang konsisten: pertama, agent cenderung mencoba menyelesaikan semuanya sekaligus dalam satu window, sehingga kehabisan konteks di tengah implementasi dan meninggalkan fitur setengah jadi tanpa dokumentasi untuk sesi berikutnya. Kedua, pada sesi-sesi selanjutnya, agent yang melihat sudah ada progres cenderung terlalu cepat menyatakan proyek selesai, padahal masih banyak fitur yang belum berfungsi.
Solusinya adalah pola harness dua bagian. Initializer agent berjalan pada sesi pertama dengan prompt khusus untuk menyiapkan lingkungan kerja: skrip init.sh untuk menjalankan server pengembangan, sebuah file progres (misalnya claude-progress.txt) yang mencatat apa saja yang sudah dikerjakan, daftar fitur terstruktur dalam format JSON (bukan Markdown, karena model cenderung lebih hati-hati mengubah JSON tanpa sengaja) dengan setiap fitur ditandai belum lulus, serta commit git awal.
Coding agent incremental kemudian dijalankan pada setiap sesi berikutnya dengan instruksi untuk mengerjakan hanya satu fitur pada satu waktu, lalu meninggalkan lingkungan dalam keadaan bersih: commit ke git dengan pesan deskriptif, perbarui file progres, dan hanya menandai fitur sebagai lulus setelah pengujian end-to-end yang sungguh-sungguh—bukan sekadar unit test atau pengecekan lewat command line. Setiap sesi baru dimulai dengan tiga langkah sederhana: memeriksa direktori kerja, membaca log git dan file progres untuk memahami konteks sebelumnya, lalu memilih fitur berprioritas tertinggi yang belum selesai dari daftar fitur.
Pola ini secara efektif memberi agent memori kolektif lintas sesi tanpa harus menyimpan seluruh riwayat percakapan—mirip semangat structured note-taking, tapi diterapkan khusus untuk konteks pengembangan software berkelanjutan.
Cara Mendiagnosis Primitif Mana yang Dibutuhkan Workload Anda
Keempat primitif di atas menangani jenis pertumbuhan konteks yang berbeda, jadi langkah pertama adalah mengidentifikasi jenis masalah yang sebenarnya dialami workload Anda, bukan langsung menumpuk semua primitif sekaligus.
Berikut peta praktis untuk mendiagnosis:
| Gejala pada workload | Primitif yang relevan | Yang perlu diperhatikan |
|---|---|---|
| Percakapan panjang bolak-balik, reasoning menumpuk | Compaction | Detail spesifik bisa hilang dalam ringkasan |
| Hasil tool besar dan bisa dipanggil ulang (baca file, API) mendominasi konteks | Tool result clearing | Perlu re-fetch jika data lama dibutuhkan lagi |
| Pekerjaan membentang lintas beberapa sesi terpisah | Structured note-taking / memory | Kualitas bergantung pada apa yang agent pilih untuk disimpan |
| Proyek besar butuh berjam-jam kerja melewati banyak context window, dengan risiko fitur setengah jadi | Initializer + incremental worker | Butuh struktur eksplisit: feature list, progress log, testing end-to-end |
Setelah memilih primitif, ukur efeknya secara konkret: lacak trajektori token per giliran, catat kapan compaction atau clearing terpicu, dan bandingkan jumlah file yang dibaca ulang atau puncak konteks antar sesi. Pada eksperimen dengan agent riset di atas, kombinasi ketiga primitif konteks (compaction, clearing, memory) sekaligus berhasil menekan puncak konteks dari 335 ribu token pada baseline menjadi sekitar 170 ribu token—namun juga menambah jumlah knob yang harus disetel dan interaksi yang harus dipahami.
Bukan berarti setiap workload butuh ketiganya. Chatbot yang setiap percakapannya memang seharusnya independen tidak butuh memory lintas sesi. Sesi yang secara alami pendek dan tidak pernah mendekati batas context window tidak butuh compaction, karena sifatnya yang lossy hanya membuang fidelitas tanpa manfaat nyata. Dan agent yang benar-benar perlu membandingkan potongan teks dari berbagai hasil tool secara berdampingan bisa dirugikan oleh clearing, karena harus melakukan fetch ulang berkali-kali.
Penutup
Tidak ada satu primitif tunggal yang paling baik untuk semua kasus. Compaction menyusutkan seluruh window saat sudah terlalu besar, clearing membuang data lama yang bisa diambil ulang dari dalam window, memory memindahkan informasi keluar window agar bertahan lintas sesi, dan pola initializer-plus-worker memberi struktur eksplisit untuk proyek yang membentang lintas banyak context window. Pertanyaan yang tepat bukan primitif mana yang paling canggih, melainkan masalah konteks spesifik apa yang sebenarnya dialami workload saya sekarang. Mulai dari situ, lalu ukur hasilnya secara langsung terhadap trajektori token dan kualitas output agent Anda.
Referensi
- Anthropic Engineering, Effective context engineering for AI agents, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Claude Cookbook, Context engineering: memory, compaction, and tool clearing, https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
- Anthropic Engineering, Effective harnesses for long-running agents, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
