Agentic Development Part 4: Context Engineering untuk Agent

Part 2 sudah menyinggung memory sebagai salah satu dari empat komponen inti agent, dan Part 3 membahas bagaimana mendesain task individual. Artikel ini menyatukan keduanya dari sudut pandang yang lebih praktis: bagaimana persisnya menyediakan context yang tepat ke agent, hari demi hari, sesi demi sesi. Ini bukan soal menulis prompt yang lebih pintar untuk satu permintaan — ini soal membangun struktur informasi yang dipakai berulang kali, oleh setiap sesi kerja, oleh setiap anggota tim, dan oleh setiap agent yang menyentuh project yang sama. Disiplin ini disebut context engineering, dan di antara seluruh praktik yang dibahas di series Agentic Development, inilah yang paling sering menentukan apakah agent bekerja dengan asumsi yang benar tentang project, atau menebak-nebak dari nol setiap kali sesi baru dimulai.

Context Engineering vs Prompt Engineering

Dua istilah ini sering dipakai bergantian, padahal fokusnya berbeda. Prompt engineering berurusan dengan bagaimana menyusun instruksi untuk satu permintaan spesifik — kata-kata mana yang dipakai, contoh seperti apa yang disertakan, format respons seperti apa yang diminta. Ini penting, tapi sifatnya sekali pakai: prompt yang bagus untuk satu permintaan tidak otomatis berguna untuk permintaan berikutnya.

Context engineering berurusan dengan sesuatu yang lebih persisten: apa yang tersedia bagi agent secara berkelanjutan sepanjang sesi kerja, bahkan sepanjang umur project. Kalau prompt adalah apa yang diketik di kotak chat untuk satu momen, context adalah keseluruhan informasi yang dibawa agent saat memproses momen itu — termasuk konvensi project, struktur codebase, keputusan arsitektur sebelumnya, dan riwayat kerja yang relevan.

flowchart LR
    subgraph PE["Prompt Engineering"]
        A[Instruksi untuk Satu Permintaan]
        A1[Sekali pakai, spesifik per momen]
    end
    subgraph CE["Context Engineering"]
        B[Konvensi Project]
        C[Struktur Codebase]
        D[Keputusan Arsitektur Sebelumnya]
        E[Spec Teknis dari Series Sebelumnya]
        B1[Persisten, dipakai berulang sepanjang sesi/project]
    end
    PE -.berjalan di atas.-> CE

Ketika seseorang membuka sesi chat baru dengan model bahasa, model itu tidak tahu apa-apa tentang project tertentu — tidak tahu bahwa project memakai PostgreSQL bukan SQLite, tidak tahu konvensi penanganan error yang sudah disepakati, tidak tahu keputusan arsitektur yang diambil bulan lalu dan alasannya. Tanpa context yang disiapkan, model akan mengisi celah ini dengan asumsi generik yang plausible tapi sering tidak cocok dengan kondisi project yang sebenarnya. Context engineering adalah praktik menyelesaikan masalah “cold start” ini sekali, dalam bentuk yang bisa dipakai ulang oleh setiap sesi berikutnya — bukan dijelaskan ulang setiap kali secara manual di setiap percakapan baru.

Pembedaan ini bukan sekadar istilah akademis. Tim yang fokus hanya pada prompt engineering — mencoba kata-kata yang lebih baik di setiap permintaan — sering mengalami hasil yang tidak konsisten antar sesi. Tim yang berinvestasi di context engineering mendapat hasil yang jauh lebih stabil, karena fondasi pemahaman project sudah benar sejak awal setiap sesi, terlepas dari bagaimana prompt spesifiknya ditulis.

Lapisan Context yang Dibutuhkan Agent

Context yang dibutuhkan agent bukan satu blok informasi tunggal, melainkan beberapa lapisan yang berbeda fungsi dan berbeda pula seberapa sering berubah.

Keempat lapisan ini idealnya tidak dicampur jadi satu dokumen besar. Konvensi project relatif stabil dan cocok dimuat penuh di awal setiap sesi. Spec teknis spesifik per fitur dan hanya relevan ketika sedang mengerjakan fitur tersebut. Codebase aktual terlalu besar untuk dimuat seluruhnya dan lebih baik diakses sesuai kebutuhan lewat pencarian, bukan dibaca penuh di depan.

flowchart TD
    A[Konvensi Project<br/>stabil, dimuat penuh di awal sesi] --> E[Context Agent Saat Bekerja]
    B[Spec Teknis Fitur Aktif<br/>per fitur, dimuat saat relevan] --> E
    C[Histori Keputusan<br/>dirujuk saat ada pertanyaan 'kenapa']--> E
    D[Codebase Aktual<br/>diakses just-in-time via search/grep] --> E

Pemisahan ini bukan sekadar soal kerapian organisasi file — ini soal mencegah satu lapisan yang berubah cepat (codebase aktual) membuat lapisan lain yang seharusnya stabil (konvensi project) menjadi sulit dipelihara karena tercampur jadi satu.

File Konvensi sebagai Persistent Context

Lapisan konvensi project, dalam praktiknya, hampir selalu diwujudkan sebagai satu file markdown yang ditempatkan di root repository dan dibaca otomatis di awal setiap sesi agent. Format ini sudah konvergen menjadi standar yang dipakai luas di berbagai tool coding agent, biasanya dengan nama seperti file instruksi project yang dibaca otomatis oleh tool yang dipakai.

Isi yang umum efektif untuk file semacam ini:

# [Nama Project] — Context untuk Agent

## Overview & Tech Stack
[Bahasa, framework, database, deployment target — ringkas]

## Struktur Project
[Layout direktori tingkat tinggi, di mana menemukan apa]

## Konvensi Kode
[Gaya penamaan, pola error handling, struktur test]

## Perintah yang Sering Dipakai
[Build, test, lint — perintah eksak yang bisa langsung dijalankan]

## Constraint dan Larangan
- JANGAN [hal spesifik yang pernah jadi masalah]
- SELALU [konvensi yang harus diikuti]

## Anti-Pattern yang Pernah Terjadi
[Kesalahan yang pernah dibuat agent sebelumnya dan bagaimana
menghindarinya — bagian ini tumbuh seiring waktu berdasarkan
kegagalan nyata, bukan ditulis spekulatif di awal]

Beberapa prinsip penting soal file ini yang didukung temuan empiris, bukan sekadar opini:

Tulis manual, jangan auto-generate dan langsung dipakai begitu saja. Studi yang membandingkan file context yang ditulis manusia versus yang digenerate otomatis oleh model menemukan hasil yang berlawanan dari intuisi: file hasil generate otomatis justru menurunkan tingkat keberhasilan task, sementara menambah biaya inferensi karena ukurannya yang membengkak. File yang dikurasi manusia memberi peningkatan performa yang jelas. Generate otomatis sebagai draft awal untuk diedit manual itu wajar, tapi men-commit hasil generate mentah tanpa kurasi adalah praktik yang sebaiknya dihindari.

Tambahkan aturan berdasarkan kegagalan nyata, bukan spekulasi. Godaan paling umum: setiap kali agent membuat kesalahan, refleks pertama adalah menambah satu aturan baru ke file konvensi. Lama-lama file ini menumpuk aturan yang saling bertentangan dan tambalan untuk kasus spesifik yang sudah tidak relevan. File yang membengkak ini justru menurunkan tingkat keberhasilan task, bukan menaikkannya — lebih banyak aturan tidak otomatis berarti hasil lebih baik.

Referensi struktur yang basi lebih berbahaya daripada tidak ada referensi sama sekali. File yang mendokumentasikan struktur direktori atau arsitektur yang sudah berubah sejak file itu ditulis justru menyesatkan agent — mendorong eksplorasi yang lebih luas dari yang dibutuhkan tanpa meningkatkan keberhasilan task.

Tempatkan aturan paling kritis di awal file, dalam bentuk bullet eksplisit. Pada sesi yang panjang, ada fenomena di mana instruksi yang “terkubur” di tengah paragraf panjang cenderung diabaikan dibanding instruksi yang ditulis sebagai bullet point di bawah heading yang jelas seperti “Constraint” atau “Jangan Lakukan”.

File konvensi yang terlalu panjang dan penuh aturan kontradiktif bukan tanda project yang well-documented — ini tanda file yang tidak pernah dirapikan. Lakukan review berkala untuk menghapus aturan yang sudah tidak relevan, bukan hanya menambah terus tanpa pernah mengurangi.

Context Window sebagai Sumber Daya Terbatas

Godaan yang wajar tapi keliru adalah berpikir “semakin banyak context yang diberikan, semakin baik hasilnya” — masukkan saja seluruh dokumentasi, seluruh histori keputusan, seluruh isi codebase, untuk berjaga-jaga supaya agent tidak kekurangan informasi. Pendekatan ini gagal karena dua alasan berbeda.

Alasan pertama: keterbatasan kapasitas. Context window, meski sudah jauh lebih besar dibanding generasi model sebelumnya, tetap punya batas. Informasi yang melebihi batas ini tidak bisa lagi diproses sama sekali.

Alasan kedua, yang lebih halus dan lebih sering diabaikan: noise mengganggu signal bahkan sebelum batas kapasitas tercapai. Informasi yang relevan bisa “tertimbun” oleh informasi yang tidak relevan, membuat agent kesulitan menemukan dan memprioritaskan detail yang penting meski secara teknis semua informasi itu masih ada di dalam context. Riset arsitektur agent mencatat bahwa rangkaian aksi otonom yang panjang membuat biaya dari kesalahan context menjadi masalah operasional kelas satu — semakin panjang rangkaian aksi sebelum campur tangan manusia, semakin besar dampak dari context yang berisik atau tidak relevan.

flowchart TD
    A[Strategi: Masukkan Semua Informasi] --> B{Di Bawah Batas Kapasitas?}
    B -- Ya --> C[Noise Tetap Mengganggu Signal]
    B -- Tidak --> D[Informasi Terpotong Tanpa Kontrol]
    C --> E[Kualitas Reasoning Menurun]
    D --> E

    F[Strategi: Selective & Just-in-Time] --> G[Hanya Informasi Relevan per Momen]
    G --> H[Signal Tetap Jernih]

Implikasi praktisnya: “masukkan semua saja untuk jaga-jaga” bukan strategi yang aman, melainkan strategi yang secara aktif menurunkan kualitas kerja agent. Pertanyaan yang lebih tepat bukan “informasi apa yang mungkin berguna”, tapi “informasi apa yang relevan untuk langkah yang sedang dikerjakan saat ini”.

Strategi Retrieval: Apa yang Dimuat, Kapan

Ada dua pendekatan dasar untuk memutuskan informasi apa yang masuk ke context agent, dan keduanya punya tempat yang tepat tergantung jenis informasinya.

Pre-loading (dimuat di awal) — cocok untuk informasi yang relatif kecil dan selalu relevan terlepas dari task spesifik apa yang sedang dikerjakan, seperti file konvensi project. Karena ukurannya terkendali dan relevansinya universal, biaya memuatnya di awal sesi sepadan dengan manfaat tidak perlu mencarinya berulang kali.

Just-in-time retrieval (dimuat saat dibutuhkan) — cocok untuk informasi yang besar atau spesifik-task, seperti isi codebase secara keseluruhan. Alih-alih memuat seluruh isi project di awal, agent menyimpan referensi ringan (path file, query yang tersimpan) dan memuat isi sebenarnya hanya ketika benar-benar dibutuhkan di langkah tertentu — menggunakan tool pencarian (mirip yang dibahas sebagai kategori tool use di Part 2) untuk menavigasi dan mengambil informasi sesuai kebutuhan saat itu.

flowchart LR
    A[Awal Sesi] --> B[Pre-load: Konvensi Project]
    B --> C[Agent Mulai Bekerja]
    C --> D{Butuh Detail Spesifik?}
    D -- Ya --> E[Just-in-Time: Search/Grep/Read File Spesifik]
    E --> C
    D -- Tidak --> F[Lanjut dengan Context yang Ada]

Pendekatan yang paling efektif dalam praktik sering kali hybrid — bukan murni salah satu. Informasi yang kecil dan selalu relevan dimuat di awal untuk kecepatan; eksplorasi lebih lanjut dilakukan secara mandiri sesuai kebutuhan, menggunakan tool navigasi yang sama seperti yang dipakai pengembang manusia untuk menjelajahi codebase asing — bukan mengandalkan index statis yang bisa basi begitu codebase berubah.

Untuk codebase yang sangat besar, sebagian tim menambahkan lapisan retrieval semantik (mirip pencarian berbasis makna, bukan sekadar pencocokan kata kunci) sebagai pelengkap navigasi langsung — berguna khususnya untuk refactoring lintas-service yang butuh pemahaman hubungan antar bagian kode yang tidak selalu terlihat dari struktur direktori semata. Tapi untuk kebanyakan project, kombinasi sederhana antara pre-loading konvensi dan pencarian just-in-time sudah cukup efektif tanpa perlu infrastruktur tambahan yang kompleks.

Mulai dari pendekatan paling sederhana: file konvensi yang dimuat penuh di awal, ditambah tool pencarian standar untuk eksplorasi just-in-time. Tambahkan lapisan retrieval yang lebih canggih hanya ketika ada bukti nyata bahwa pendekatan sederhana ini sudah tidak memadai — bukan dibangun di muka karena terdengar lebih canggih.

Menjaga Context Tetap Segar: Update Berkelanjutan

Masalah spec yang basi sudah dibahas di Part 4 series Spec-Driven Development — spec yang akurat saat ditulis tapi tidak pernah diupdate seiring implementasi berjalan, sehingga jadi sumber kebingungan di sesi berikutnya. Masalah yang sama persis berlaku untuk file context: konvensi yang didokumentasikan bisa dengan cepat menyimpang dari kenyataan begitu project terus berkembang.

Bedanya dengan spec, file context biasanya berumur lebih panjang dan dipakai lebih sering — sehingga biaya membiarkannya basi jauh lebih besar. Spec untuk satu fitur basi hanya mempengaruhi fitur itu; file konvensi yang basi mempengaruhi setiap sesi kerja berikutnya, tanpa kecuali.

Praktik yang efektif untuk mencegah ini:

• Update sebagai bagian dari definition of done — sama seperti praktik di Part 4 series Spec-Driven Development, ketika sebuah task mengubah konvensi yang terdokumentasi, update file context adalah bagian dari “task selesai”, bukan langkah administratif terpisah yang mudah ditunda
• Versi terkontrol seperti kode — file konvensi diperlakukan sebagai bagian dari repository yang sama, direview lewat proses yang sama dengan perubahan kode, bukan diedit bebas tanpa jejak
• Review berkala terjadwal — selain update reaktif saat konvensi berubah, tinjauan rutin (misalnya tiap kuartal) untuk menghapus panduan yang sudah usang membantu mencegah penumpukan aturan yang saling bertentangan dari waktu ke waktu

File context yang basi lebih berbahaya daripada tidak adanya file context sama sekali. Tanpa file, agent setidaknya akan mengeksplorasi codebase secara langsung untuk memahami kondisi aktual. Dengan file yang basi, agent mempercayai informasi yang salah sebagai kebenaran, dan kesalahan ini bisa menjalar ke setiap keputusan berikutnya tanpa terdeteksi sampai jauh kemudian.

Context untuk Sesi Panjang dan Multi-Sesi

Task yang kompleks sering membutuhkan banyak iterasi loop plan-act-observe (dibahas di Part 1 dan Part 2), dan ini menciptakan tantangan tersendiri: riwayat percakapan dan hasil tool call yang terus bertambah lama-lama mendekati batas context window, meski sesi itu sendiri belum selesai.

Strategi yang dipakai untuk menangani ini disebut compaction — meringkas riwayat panjang menjadi versi yang lebih padat, mempertahankan informasi yang masih relevan sambil membuang yang sudah tidak dibutuhkan. Yang membuat compaction sulit dilakukan dengan baik bukan teknik meringkasnya, tapi keputusan apa yang dipertahankan dan apa yang dibuang — keputusan arsitektur dan detail implementasi yang belum selesai perlu dipertahankan, sementara hasil tool call yang sifatnya sekali pakai dan sudah tidak relevan bisa dibuang dengan aman.

flowchart TD
    A[Sesi Panjang Berjalan] --> B{Context Mendekati Batas?}
    B -- Belum --> A
    B -- Ya --> C[Compaction: Ringkas Riwayat]
    C --> D[Pertahankan: Keputusan Arsitektur,<br/>Bug yang Belum Selesai, Detail Implementasi]
    C --> E[Buang: Hasil Tool Call Sekali Pakai<br/>yang Sudah Tidak Relevan]
    D --> F[Lanjutkan Sesi dengan Context Terkompresi]
    E --> F

Pendekatan komplementer yang lebih sederhana, dan sering lebih andal, adalah externalizing state — menyimpan progres kerja ke file eksternal alih-alih hanya mengandalkan ingatan dalam context window. Pola sederhana semacam catatan kemajuan kerja yang terus diperbarui (mirip to-do list yang ditulis dan dibaca ulang agent) memungkinkan agent melacak progres dan dependency antar langkah lintas banyak tool call, tanpa kehilangan jejak meskipun context window perlu dikompresi atau bahkan sesi perlu dimulai ulang dari awal.

Untuk pekerjaan yang benar-benar melintasi banyak sesi terpisah — bukan hanya satu sesi panjang — pola yang efektif adalah menutup setiap sesi dengan menulis ringkasan eksplisit ke file (apa yang sudah selesai, apa yang masih tertunda, keputusan apa yang diambil dan kenapa), supaya sesi berikutnya tidak perlu menebak ulang dari nol kondisi terakhir pekerjaan ditinggalkan.

Tanda sesi sudah terlalu “kotor” untuk dilanjutkan dengan baik: campuran beberapa task yang tidak berhubungan dalam satu sesi yang sama, atau koreksi berulang terhadap kesalahan yang sama tanpa membaik. Pada titik ini, memulai sesi baru dengan context yang bersih — dibantu ringkasan tertulis dari sesi sebelumnya — sering lebih produktif daripada memaksakan sesi yang sudah penuh riwayat yang membingungkan untuk terus berlanjut.

Anti-Pattern dalam Context Engineering

Beberapa pola yang sering muncul dan melemahkan efektivitas context meski terlihat seperti usaha yang baik di permukaan:

Context overload — memasukkan semua “untuk jaga-jaga”. Sudah dibahas di atas: lebih banyak informasi tidak otomatis berarti hasil lebih baik, dan noise yang berlebihan justru mengganggu signal yang penting, bahkan sebelum context window benar-benar penuh.

Context yang basi. File konvensi atau referensi struktur yang tidak pernah diupdate seiring project berubah, menyesatkan agent dengan informasi yang terlihat otoritatif tapi sudah tidak akurat.

Tidak ada struktur, sehingga agent harus “menebak” tiap sesi. Tanpa file context yang jelas, setiap sesi baru dimulai dari nol — agent harus menyimpulkan ulang konvensi project dari membaca kode yang ada, dengan hasil yang bervariasi tergantung file mana yang kebetulan dieksplorasi lebih dulu.

Over-reliance pada satu file besar tanpa hierarki. Mencampur konvensi yang stabil, spec teknis spesifik fitur, dan detail implementasi yang sangat granular jadi satu file tunggal yang terus membengkak. Pemisahan lapisan seperti dibahas di awal artikel ini — konvensi terpisah dari spec fitur, terpisah dari codebase aktual — mencegah satu file menjadi terlalu besar dan terlalu sulit dirawat untuk tetap akurat.

Menambah aturan secara reaktif tanpa pernah menghapus. Pola yang sudah disinggung di bagian file konvensi — setiap kegagalan direspons dengan menambah satu aturan baru, tanpa pernah meninjau ulang apakah aturan-aturan lama masih relevan atau justru sudah saling bertentangan dengan aturan yang lebih baru.

Tanda paling jelas context engineering yang belum matang bukan “agent membuat kesalahan” — itu akan selalu terjadi sesekali. Tandanya adalah kesalahan yang sama berulang di sesi-sesi berbeda meski sudah pernah “diperbaiki” sebelumnya, yang biasanya berarti perbaikan itu hanya diberikan sebagai koreksi sesaat dalam percakapan, bukan benar-benar masuk ke context persisten yang dibaca sesi-sesi berikutnya.

Ringkasan

• Context engineering berbeda dari prompt engineering: prompt adalah instruksi sekali pakai untuk satu momen, context adalah informasi persisten yang dibawa agent sepanjang sesi dan lintas sesi
• Context yang dibutuhkan agent berlapis-lapis — konvensi project (stabil, dimuat penuh), spec teknis (per fitur, dari series Spec-Driven Development), histori keputusan, dan codebase aktual (diakses just-in-time) — dan sebaiknya tidak dicampur jadi satu dokumen besar
• File konvensi project paling efektif ketika ditulis dan dikurasi manusia, bukan auto-generate yang langsung dipakai — studi empiris menunjukkan file hasil generate otomatis justru menurunkan tingkat keberhasilan task
• Tambahkan aturan ke file konvensi berdasarkan kegagalan nyata yang teramati, bukan spekulasi — file yang membengkak dengan aturan kontradiktif menurunkan performa, bukan menaikkannya
• “Masukkan semua informasi untuk jaga-jaga” adalah strategi yang keliru — noise mengganggu signal bahkan sebelum context window penuh, sehingga selective retrieval lebih efektif daripada memuat semuanya
• Kombinasikan pre-loading (untuk informasi kecil dan selalu relevan) dengan just-in-time retrieval (untuk informasi besar atau spesifik-task) — pendekatan hybrid ini lebih efektif dibanding murni salah satu
• File context yang basi lebih berbahaya daripada tidak ada file sama sekali — update context adalah bagian dari definition of done, sama seperti update spec di series sebelumnya
• Untuk sesi panjang, gunakan compaction (meringkas riwayat sambil mempertahankan keputusan penting) dan externalizing state (menyimpan progres ke file eksternal) supaya pekerjaan tidak kehilangan jejak meski context dikompresi atau sesi dimulai ulang