Context Engineering untuk Agen LLM: Write, Select, Compress

Foto oleh Eilis Garvey on Unsplash
Context engineering adalah disiplin menyusun dan menjaga kumpulan token optimal yang dilihat LLM selama inferensi: system prompt, tools, data hasil retrieval, memory, dan riwayat percakapan. Untuk agen yang berjalan banyak giliran, ia mengelola seluruh keadaan informasi di tiap langkah, bukan hanya satu prompt. Anthropic menyebutnya kelanjutan alami dari prompt engineering.
Prompt engineering berfokus pada susunan kata satu instruksi yang ditulis sekali sebelum pemanggilan. Context engineering mengatur seluruh kumpulan token yang dirakit di setiap langkah, termasuk tools, dokumen, memory, dan history. Prompt engineering kini dianggap bagian dari context engineering, karena pada agen nyata prompt hanyalah satu input di antara banyak.
Istilahnya populer pada Juni 2025. CEO Shopify Tobi Lutke mendukungnya pada 19 Juni, dan Andrej Karpathy memperkuatnya pada 25 Juni, menyebutnya seni dan sains mengisi context window dengan informasi tepat untuk langkah berikutnya. Anthropic kemudian menerbitkan panduan teknik resmi tentangnya pada September 2025.
Drew Breunig mencatat empat mode: poisoning (kesalahan dirujuk berulang), distraction (model terlalu fokus pada konteks panjang), confusion (tools atau konten berlebih menurunkan kualitas), dan clash (informasi baru berbenturan dengan yang lama). Anthropic secara terpisah menjelaskan context rot, di mana akurasi recall menurun seiring bertambahnya token.
LangChain mengelompokkannya menjadi write, select, compress, dan isolate. Write menyimpan informasi di luar window (scratchpad, memory); select menarik hanya token relevan lewat RAG dan pemuatan tepat waktu; compress meringkas atau memangkas token (Claude Code auto-compact di sekitar 95% pemakaian); isolate memisahkan pekerjaan ke sub-agen yang mengembalikan ringkasan padat.

Foto oleh Eilis Garvey on Unsplash
Ringkasan Utama
Context engineering adalah disiplin mengatur token mana persisnya yang dilihat agen LLM di setiap langkah: system prompt, tools, data hasil retrieval, memory, dan history. Ia menggantikan prompt engineering untuk agen produksi pada 2025 karena mayoritas kegagalan agen adalah kegagalan konteks, bukan kegagalan model, dan membebani window justru menurunkan akurasi.
Selama dua tahun keahlian ini disebut prompt engineering, dan umumnya berarti memoles satu instruksi cerdas sampai sebuah chatbot berperilaku benar. Kerangka itu runtuh saat saya mulai mengirim agen yang berjalan ratusan giliran, memanggil tools, dan membaca dokumen. Ternyata susunan kata pada prompt hanyalah sebagian kecil dari penentu keberhasilan. Segala hal lain di dalam window, potongan hasil retrieval, output tools, riwayat percakapan, dan memory, jauh lebih menentukan.
Di tulisan ini saya bahas apa sebenarnya context engineering, mengapa istilahnya mengkristal pada 2025, cara-cara spesifik sebuah context window gagal, empat strategi yang saya pakai untuk menjaganya tetap sehat, dan angka-angka terpublikasi yang menunjukkan dampaknya. Setiap angka di sini bersumber dari primary source yang ditautkan di akhir.
Istilah ini populer pada Juni 2025. Pada 19 Juni, CEO Shopify Tobi Lutke menulis bahwa ia lebih suka context engineering daripada prompt engineering karena menggambarkan keahlian intinya dengan lebih baik: seni menyediakan seluruh konteks agar tugas masuk akal untuk diselesaikan oleh model. Enam hari kemudian, pada 25 Juni, Andrej Karpathy mendukungnya, menyebut context engineering sebagai seni dan sains yang cermat dalam mengisi context window dengan informasi yang tepat untuk langkah berikutnya. Pada September 2025 Anthropic menerbitkan panduan teknik yang mendefinisikannya sebagai strategi untuk menyusun dan menjaga kumpulan token yang optimal selama inferensi model.
Pergeseran pola pikir utamanya adalah prompt engineering kini menjadi bagian dari context engineering. Menulis instruksi yang baik tetap penting, tetapi dalam agen nyata ia hanya satu input di antara banyak input. Anthropic membingkai context engineering sebagai kelanjutan alami prompt engineering: alih-alih menyusun satu prompt, Anda mengelola seluruh keadaan informasi yang dilihat model di setiap giliran.
| Dimensi | Prompt engineering | Context engineering |
|---|---|---|
| Cakupan | Satu prompt yang ditulis tangan | Seluruh kumpulan token di setiap giliran |
| Unit kerja | Susunan kata satu instruksi | System prompt, tools, data retrieval, memory, history |
| Kapan berjalan | Sekali, sebelum pemanggilan | Terus-menerus, dibangun ulang di tiap langkah |
| Risiko kegagalan utama | Instruksi yang samar atau kikuk | Membebani window sampai recall menurun |
Konteks yang lebih panjang tidak otomatis lebih baik. Anthropic menyebutnya context rot: seiring jumlah token bertambah, kemampuan model mengingat informasi dari konteks itu secara akurat menurun, karena perhatian tersebar ke lebih banyak relasi antar-pasangan. Drew Breunig mencatat empat cara konkret konteks gagal, masing-masing dengan bukti dari studi publik.
Konteks lebih banyak bukan peningkatan gratis. Model dengan window sejuta token pun bisa kehilangan alur pada sebagian kecil dari batas itu, jadi perlakukan setiap token yang Anda tambahkan sebagai biaya, bukan fitur. Jika sebuah potongan tidak membantu langkah berikutnya, membuangnya biasanya justru memperbaiki jawaban.
LangChain mengelompokkan teknik yang bekerja ke dalam empat kategori, dengan analogi yang berguna: context window itu seperti RAM, sumber daya terbatas yang dikurasi sistem operasi. Hampir semua yang saya lakukan di produksi memetakan ke salah satu dari empat kata kerja ini.
Berikut bentuk satu giliran agen ketika Anda memperlakukan konteks sebagai anggaran. Ia menulis inti kecil yang stabil, memilih hanya tools dan dokumen yang cocok dengan tujuan, lalu mengompres history begitu mendekati batas. Intinya, perakitan konteks adalah kode yang Anda miliki, dijalankan di setiap langkah, bukan prompt sekali jalan.
# One agent turn: assemble context under a fixed token budget
MAX_TOKENS = 180_000
COMPACT_AT = 0.95 # Claude Code auto-compacts near 95% utilization
def build_context(state):
# WRITE once, keep it small: system prompt + a few canonical examples
ctx = [state.system_prompt, *state.canonical_examples]
# SELECT: RAG over tool specs and docs — pull the few that fit the goal,
# not all 40 tools (more tools measurably lowers tool-call accuracy)
ctx += select_relevant(state.tools, state.goal, top_k=5)
# SELECT just-in-time: keep lightweight IDs, load full docs only on demand
ctx += retrieve(state.query, top_k=5)
ctx += state.recent_messages
# COMPRESS: if we near the budget, summarize the oldest turns and
# keep decisions, open bugs, and file paths — then drop the raw history
if count_tokens(ctx) > MAX_TOKENS * COMPACT_AT:
summary = summarize(state.older_messages,
keep=["decisions", "open_bugs", "file_paths"])
ctx = replace(ctx, state.older_messages, summary)
return ctx # ISOLATE heavy sub-tasks in sub-agents that return ~1-2k tokens
Saran praktis Anthropic: mulai dengan prompt terkecil pada model terbaik yang Anda punya, lalu tambahkan instruksi hanya di tempat Anda mengamati kegagalan nyata. Utamakan beberapa contoh kanonik yang beragam daripada daftar panjang kasus tepi. Konteks ramping yang Anda tumbuhkan dengan sengaja mengalahkan konteks bengkak yang Anda pangkas belakangan.
Alasan hal ini berhenti menjadi opsional adalah karena angkanya besar dan berulang. Penurunan 39 persen pada multi-giliran, skor o3 runtuh dari 98,1 ke 64,1, akurasi tools pulih ketika himpunan menyusut dari 46 ke 19, dan akurasi merosot di 32k token bukanlah kasus tepi. Itulah perilaku bawaan model yang mumpuni ketika diberi konteks yang buruk kurasinya.
Maka aturan saya ketika sebuah agen berperilaku aneh adalah memeriksa konteks sebelum menyalahkan model. Sembilan dari sepuluh kali solusinya adalah lebih sedikit tools, kueri retrieval yang lebih ketat, ringkasan dua puluh giliran terakhir, atau sub-agen untuk mengisolasi sub-tugas yang berisik. Context engineering adalah pekerjaan pipa yang tak glamor, dan ia adalah pekerjaan berdaya ungkit tertinggi dalam membangun agen yang tahan di produksi.