Agentic Development Part 2: Anatomi Coding Agent

Part 1 memperkenalkan loop dasar agent: plan, act, observe, ulangi sampai tujuan tercapai. Loop ini terdengar sederhana dalam diagram, tapi di baliknya ada empat komponen berbeda yang masing-masing punya cara gagal sendiri-sendiri — dan memahami komponen ini satu per satu adalah prasyarat untuk mendesain task yang baik (Part 3), menyediakan context yang tepat (Part 4), dan membangun guardrail yang efektif (Part 5). Artikel ini membedah anatomi coding agent: planner yang menyusun rencana, tool use yang menjadi “tangan” agent untuk bertindak, memory yang mengelola apa yang diingat agent sepanjang sesi kerja, dan observation yang memverifikasi hasil sebelum melangkah ke iterasi berikutnya. Di production, agent bukan sekadar prompt yang dipanggil sekali — ia adalah sistem terdistribusi di mana model bahasa kebetulan berperan sebagai planner dan executor-nya, dan seperti sistem terdistribusi lainnya, reliabilitasnya datang dari arsitektur, bukan dari seberapa pintar satu komponennya saja.

Komponen Inti: Planner

Planner adalah komponen yang menerjemahkan tujuan tingkat tinggi — baik berupa spec lengkap dari series sebelumnya maupun instruksi singkat — menjadi urutan langkah konkret yang bisa dieksekusi. Ini bukan sekadar “agent memikirkan apa yang harus dilakukan”, tapi proses yang punya struktur: memahami state saat ini, membandingkannya dengan tujuan akhir, dan menyusun jalur dari satu ke yang lain.

Ada perbedaan penting antara dua gaya planning yang sering tercampur dalam diskusi tentang agent:

Plan statis — disusun sekali di awal, lalu dieksekusi langkah demi langkah tanpa revisi, meskipun kondisi di lapangan berubah. Plan statis cocok untuk task yang sangat well-defined dan tidak mengandung kejutan, tapi rapuh begitu asumsi awal ternyata salah. Plan yang disusun dengan asumsi “skema database sudah seperti ini” akan terus dieksekusi sesuai asumsi itu meskipun langkah ketiga menemukan bahwa skemanya ternyata berbeda.

Plan dinamis — disusun ulang atau disesuaikan setiap kali ada temuan baru yang relevan. Begitu langkah eksekusi mengungkap informasi yang tidak terduga, planner mengevaluasi ulang apakah rencana sisanya masih valid, dan menyesuaikan jika perlu. Ini yang membuat agent terasa “cerdas” dibanding sekadar menjalankan script — bedanya bukan di kemampuan bahasa, tapi di kemampuan merevisi rencana berdasarkan observasi baru.

flowchart TD
    A[Terima Tujuan] --> B[Pahami State Saat Ini]
    B --> C[Susun Rencana Awal]
    C --> D[Eksekusi Langkah]
    D --> E{Temuan Baru Mengubah Asumsi?}
    E -- Tidak --> F[Lanjut Langkah Berikutnya]
    E -- Ya --> G[Revisi Rencana]
    G --> D
    F --> D

Untuk task yang kompleks, planner sering bekerja secara hierarkis — bukan menyusun satu daftar langkah datar, tapi memecah tujuan besar jadi sub-tujuan, yang masing-masing baru direncanakan detail langkahnya ketika gilirannya tiba. Pola ini konsisten dengan pemecahan spec menjadi task group yang sudah dibahas di Part 4 series Spec-Driven Development — plan hierarkis pada level agent pada dasarnya adalah cermin dari plan hierarkis pada level proses kerja manusia-agent.

Riset terbaru tentang arsitektur agent menekankan praktik memisahkan secara eksplisit antara fase planning dan fase eksekusi: planner mengusulkan rencana lengkap dengan constraint dan kriteria sukses, baru kemudian executor menjalankan rencana itu di bawah pembatasan tool yang lebih ketat. Pemisahan ini meningkatkan kontrol — rencana bisa direview manusia sebelum dieksekusi (persis pola “plan mode” yang disinggung di Part 4 series sebelumnya) — dan mengurangi besarnya dampak ketika ada kegagalan, karena kesalahan di fase eksekusi tidak otomatis berarti seluruh rencana harus disusun ulang dari nol.

Planner yang baik bukan yang menghasilkan rencana paling detail, tapi yang tahu kapan rencana perlu direvisi. Tanda planner yang lemah: terus mengeksekusi langkah sesuai rencana awal meskipun observasi di tengah jalan sudah jelas-jelas bertentangan dengan asumsi yang dipakai menyusun rencana tersebut.

Komponen Inti: Tool Use

Planner yang sempurna tanpa kemampuan bertindak hanyalah wacana. Tool use adalah komponen yang mengubah rencana menjadi perubahan nyata — membaca dan menulis file, menjalankan perintah shell, mencari pola di codebase, memanggil API eksternal, atau menggunakan tool dari MCP server yang terhubung.

Beberapa kategori tool yang umum dipakai coding agent:

Tool bukan sekadar fungsi yang dipanggil — tool adalah API yang perlu didesain dengan kontrak yang jelas, persis seperti kontrak API yang dibahas di Part 3 series Spec-Driven Development. Setiap tool sebaiknya memvalidasi input dan output, idempoten untuk efek samping yang bisa diulang dengan aman, dan punya batas waktu/biaya yang jelas. Tool yang didesain longgar — menerima input apa saja, gagal secara diam-diam tanpa pesan error yang jelas — adalah sumber kegagalan agent yang sulit dilacak, karena masalahnya bukan di reasoning model, tapi di lapisan tindakan yang tidak transparan terhadap kegagalannya sendiri.

Pemilihan tool yang tepat untuk situasi tertentu juga bagian dari kemampuan agent yang sering diabaikan dalam diskusi umum. Agent yang baik tidak langsung menjalankan perintah shell untuk mencari sesuatu yang lebih cepat dan akurat ditemukan lewat tool search khusus, atau tidak menulis ulang seluruh file ketika perubahan satu baris sudah cukup. Pemilihan tool yang tidak tepat bukan hanya soal efisiensi — tool yang lebih invasif dari yang dibutuhkan (misalnya menjalankan perintah destruktif padahal cukup membaca) meningkatkan risiko tanpa manfaat tambahan.

Tool dengan efek samping yang tidak idempoten — menjalankan perintah yang sama dua kali menghasilkan akibat berbeda dari sekali — adalah risiko tersembunyi dalam loop agent. Kalau agent mengulang langkah karena observasi sebelumnya tidak jelas, tool yang tidak idempoten bisa menghasilkan state yang rusak tanpa agent menyadarinya.

Komponen Inti: Memory dan Context Management

Memory mengontrol informasi apa yang tersedia bagi agent selama bekerja, dan ini salah satu komponen yang paling sering disalahpahami. Anggapan keliru yang umum adalah menyamakan “memory” dengan satu mekanisme tunggal seperti vector database — padahal memory yang efektif adalah sistem berlapis, bukan satu lapisan saja.

Working memory (context window) — informasi yang aktif dipakai agent dalam satu sesi kerja saat ini: instruksi, isi file yang sedang dibaca, hasil tool call sebelumnya, dan riwayat percakapan. Working memory ini terbatas ukurannya, dan inilah constraint paling nyata yang membentuk bagaimana agent bekerja sehari-hari — bukan keterbatasan kecerdasan, tapi keterbatasan berapa banyak informasi yang bisa “dipegang” sekaligus.

Persistent memory (lintas sesi) — informasi yang bertahan melewati batas satu sesi kerja, biasanya disimpan sebagai file konvensi project (seperti file konfigurasi yang dibaca agent di awal sesi untuk memahami struktur dan aturan project), ringkasan keputusan arsitektur sebelumnya, atau preferensi yang sudah disepakati. Berbeda dari working memory yang hilang begitu sesi berakhir, persistent memory inilah yang membuat agent di sesi berikutnya tidak perlu “berkenalan ulang” dengan project dari nol.

Episodic memory — catatan tentang kejadian spesifik di masa lalu: apa yang terjadi, kapan, dan dalam urutan apa. Ini berguna ketika agent perlu memahami histori perubahan — misalnya kenapa suatu pendekatan sebelumnya pernah dicoba dan ditolak, supaya tidak mengulang kesalahan yang sama di sesi berikutnya.

flowchart TD
    subgraph Working["Working Memory - per sesi"]
        A[Instruksi Saat Ini]
        B[Isi File yang Dibaca]
        C[Hasil Tool Call]
    end
    subgraph Persistent["Persistent Memory - lintas sesi"]
        D[Konvensi Project]
        E[Keputusan Arsitektur Sebelumnya]
        F[Spec Teknis: ERD, API Contract]
    end
    Persistent -.dibaca di awal sesi.-> Working
    Working -.temuan penting disimpan balik.-> Persistent

Diagram di atas menunjukkan kenapa spec teknis dari series Spec-Driven Development — ERD, kontrak API, file konvensi — secara fungsional adalah bagian dari persistent memory agent. Spec yang sama yang dibahas sebagai “kontrak untuk manusia merencanakan kerja” di series sebelumnya, dari sudut pandang arsitektur agent, juga berfungsi sebagai sumber context yang dibaca di awal setiap sesi supaya agent tidak perlu menebak ulang keputusan teknis yang sudah disepakati.

Karena working memory terbatas, strategi mengelola apa yang masuk dan keluar dari context window menjadi keterampilan tersendiri — sering disebut context engineering. Beberapa strategi yang umum dipakai:

• Summarization — meringkas riwayat percakapan atau hasil eksplorasi panjang menjadi versi padat, supaya detail yang sudah tidak relevan tidak terus memakan ruang context
• Selective retrieval — hanya memuat bagian codebase atau dokumentasi yang relevan dengan task saat ini, bukan seluruh project sekaligus
• Externalizing state — menyimpan progres kerja (misalnya status task group, seperti dibahas di Part 4 series sebelumnya) ke file eksternal, sehingga kalau context window perlu “direset” di tengah sesi panjang, state pekerjaan tidak ikut hilang

Context window yang penuh bukan cuma soal kapasitas — informasi yang relevan bisa “tertimbun” oleh informasi yang tidak relevan, membuat agent kesulitan menemukan detail penting meski secara teknis informasi itu masih ada di dalam context. Mengelola apa yang masuk ke context sama pentingnya dengan mengelola ukurannya.

Komponen Inti: Observation dan Self-Verification

Observation adalah komponen yang sering paling diremehkan, padahal inilah yang menentukan apakah loop agent benar-benar belajar dari tindakannya atau sekadar bergerak maju secara membabi buta. Observation berarti agent membaca dan menafsirkan hasil dari tindakan yang baru dilakukan — output perintah yang dijalankan, hasil test, perbedaan antara state yang diharapkan dan state aktual — sebelum memutuskan langkah berikutnya.

Beda agent yang melakukan observation dengan baik dan yang tidak terlihat jelas dalam skenario sederhana: agent menjalankan test, dan test tersebut gagal.

ANTI-PATTERN (observation dangkal):
Agent menjalankan command test, melihat ada output (apapun isinya),
menganggap "sudah dijalankan" sebagai tanda task selesai, lanjut ke
langkah berikutnya tanpa membaca apakah test itu lolos atau gagal.

BENAR (observation dengan verifikasi):
Agent menjalankan command test, membaca exit code dan isi output,
mengidentifikasi test mana yang gagal dan kenapa, lalu menyesuaikan
rencana untuk memperbaiki kegagalan tersebut sebelum melanjutkan ke
langkah berikutnya.

Self-verification yang efektif tidak berhenti di “apakah perintah berhasil dijalankan tanpa error”, tapi sampai ke “apakah hasilnya benar-benar sesuai yang dimaksud”. Ini menghubungkan langsung ke masalah yang dibahas di Part 5 series Spec-Driven Development — kode bisa lolos test secara teknis tapi tetap melenceng dari intent. Observation yang baik memeriksa terhadap acceptance criteria yang relevan, bukan hanya terhadap “apakah ada error di console”.

flowchart LR
    A[Eksekusi Tindakan] --> B[Baca Output/Hasil]
    B --> C{Sesuai Acceptance Criteria?}
    C -- Ya --> D[Lanjut ke Langkah Berikutnya]
    C -- Tidak Jelas --> E[Gali Lebih Dalam / Tool Tambahan]
    C -- Tidak --> F[Revisi Pendekatan]
    E --> C
    F --> A

Self-verification yang dangkal — menganggap “tidak ada error” sebagai bukti “berhasil” — adalah salah satu sumber paling umum dari kegagalan agent yang sulit terdeteksi sampai jauh kemudian. Perintah bisa berjalan tanpa error sama sekali sambil tetap menghasilkan output yang salah, terutama untuk kasus seperti silent failure (operasi gagal secara senyap tanpa exception), atau hasil yang valid secara sintaks tapi salah secara logika.

Diagram Arsitektur Lengkap

Menggabungkan keempat komponen di atas menjadi satu gambaran arsitektur utuh, dengan spec teknis dari series Spec-Driven Development sebagai input yang mengalir ke planner di awal dan jadi rujukan verifikasi di observation:

flowchart TD
    Spec[Spec Teknis: Intent, Constraint,<br/>Acceptance Criteria, ERD, API Contract] --> Planner

    subgraph Loop["Loop Agent"]
        Planner[Planner: Susun/Revisi Rencana] --> ToolUse[Tool Use: Eksekusi via File/Shell/API]
        ToolUse --> Observation[Observation: Baca & Evaluasi Hasil]
        Observation -->|Sesuai| NextStep{Tujuan Tercapai?}
        Observation -->|Tidak Sesuai| Planner
        NextStep -- Belum --> Planner
    end

    Memory[(Persistent Memory:<br/>Konvensi Project, Histori Keputusan)] -.tersedia sepanjang loop.-> Planner
    Memory -.tersedia sepanjang loop.-> Observation

    Spec -.rujukan verifikasi.-> Observation
    NextStep -- Ya --> Done[Task Selesai]

Diagram ini menunjukkan dua jalur masuk spec ke dalam arsitektur agent: pertama sebagai input awal yang membentuk rencana planner, kedua sebagai rujukan yang dipakai observation untuk menilai apakah hasil tindakan benar-benar sesuai yang dimaksud — bukan hanya “terlihat berhasil” secara permukaan. Memory persisten menyediakan konteks project yang sama ke kedua komponen ini, memastikan keputusan yang diambil planner dan standar yang dipakai observation tetap konsisten sepanjang sesi kerja, bahkan ketika sesi tersebut berlangsung lama dan melibatkan banyak iterasi loop.

Single Agent vs Sub-agent dalam Satu Task

Sebelum masuk ke topik orkestrasi multi-agent penuh yang akan dibahas di Part 6, ada pola yang lebih sederhana dan lebih sering dipakai sehari-hari: dalam satu sesi kerja, agent utama bisa mendelegasikan sebagian pekerjaan ke sub-agent yang lebih terspesialisasi, lalu menggabungkan hasilnya kembali ke alur kerja utama.

Bedanya dengan orkestrasi multi-agent penuh ada di skala dan independensi: sub-agent dalam satu task biasanya berumur pendek, dibuat untuk satu sub-pekerjaan spesifik, lalu hasilnya langsung diserap kembali oleh agent utama. Orkestrasi multi-agent yang akan dibahas di Part 6 melibatkan beberapa agent yang masing-masing punya peran independen dan berjalan lebih lama, sering kali dengan agent koordinator terpisah yang mengatur keseluruhan alur.

Kapan pola sub-agent dalam satu task ini bermanfaat:

• Eksplorasi paralel yang independen — misalnya mencari pola penggunaan suatu fungsi di banyak bagian codebase sekaligus, di mana setiap pencarian tidak bergantung satu sama lain
• Sub-task yang butuh fokus sempit — agent utama mendelegasikan analisis satu file kompleks ke sub-agent yang context-nya dibatasi hanya pada file tersebut, supaya hasil analisisnya lebih tajam tanpa “terdistraksi” oleh keseluruhan codebase
• Menjaga context window agent utama tetap ringkas — hasil eksplorasi panjang dari sub-agent diringkas sebelum dikembalikan ke agent utama, mencegah context window utama penuh oleh detail eksplorasi yang sebenarnya tidak semuanya relevan untuk keputusan berikutnya

Kapan satu agent saja sudah cukup, tanpa perlu sub-agent:

• Task yang scope-nya kecil dan tidak membutuhkan eksplorasi luas
• Pekerjaan yang sifatnya sekuensial ketat, di mana setiap langkah bergantung penuh pada hasil langkah sebelumnya — delegasi paralel di sini tidak memberi manfaat, malah menambah kompleksitas koordinasi

Pertimbangkan sub-agent ketika pekerjaan punya bagian yang bisa dieksplorasi independen dan hasilnya bisa diringkas menjadi sesuatu yang ringkas untuk dikonsumsi agent utama. Kalau hasilnya tetap perlu detail penuh untuk dipahami, manfaat sub-agent berkurang karena context yang dihemat di satu sisi akan kembali membengkak saat hasil lengkap dikembalikan.

Kegagalan Umum di Tiap Komponen

Memahami komponen secara terpisah juga memudahkan mendiagnosis di mana sebenarnya kegagalan terjadi ketika agent menghasilkan output yang buruk — alih-alih menyalahkan “AI-nya kurang pintar” secara umum.

Kegagalan di Planner

• Rencana terlalu dangkal — langsung lompat ke eksekusi tanpa benar-benar memahami state saat ini, menghasilkan langkah-langkah yang berdasarkan asumsi yang tidak diverifikasi
• Rencana terlalu dalam — menghabiskan terlalu banyak putaran reasoning untuk task yang sebenarnya sederhana, memperlambat eksekusi tanpa manfaat tambahan
• Tidak merevisi rencana meski ada temuan baru — kasus yang sudah disinggung di atas, plan statis yang dipaksakan meski kondisi sudah berubah

Kegagalan di Tool Use

• Memilih tool yang salah untuk situasi — menjalankan perintah shell yang invasif padahal tool pencarian yang lebih aman sudah cukup
• Tidak menangani error dari tool dengan baik — tool gagal dijalankan, tapi agent melanjutkan seolah-olah berhasil karena tidak memeriksa status keberhasilan secara eksplisit
• Efek samping yang tidak idempoten dijalankan berulang — seperti dibahas di atas, berisiko menghasilkan state yang rusak ketika agent mengulang langkah karena ketidakjelasan observasi sebelumnya

Kegagalan di Memory dan Context

• Context overflow — informasi penting “terdesak keluar” karena context window penuh dengan detail yang kurang relevan, terutama pada sesi kerja yang panjang tanpa strategi summarization yang baik
• Informasi penting hilang antar sesi — keputusan arsitektur atau konvensi project yang seharusnya persisten, tapi tidak pernah disimpan ke memory persisten, sehingga harus “ditemukan ulang” setiap sesi baru dimulai
• Memory yang basi — konvensi atau keputusan yang tersimpan di memory persisten sudah tidak relevan lagi karena project berubah, tapi tetap dipakai sebagai rujukan tanpa diperbarui — masalah yang sama persis dengan spec yang basi yang dibahas di Part 4 series sebelumnya

Kegagalan di Observation

• Verifikasi dangkal — menganggap “tidak ada error” setara dengan “hasil benar”, tanpa memeriksa terhadap acceptance criteria yang sebenarnya
• Tidak menggali lebih dalam ketika hasil ambigu — observasi yang tidak jelas seharusnya memicu eksplorasi tambahan, bukan diasumsikan baik-baik saja dan dilanjutkan begitu saja
• Mengabaikan sinyal kegagalan yang halus — seperti silent failure atau hasil yang valid secara teknis tapi salah secara logika, yang butuh pemeriksaan lebih dari sekadar exit code

Kegagalan paling berbahaya bukan yang menghasilkan error jelas — itu mudah terdeteksi dan diperbaiki. Kegagalan yang paling berbahaya adalah yang lolos semua pemeriksaan dangkal tapi tetap salah secara substansi, karena kegagalan ini bisa menjalar melalui beberapa iterasi loop sebelum akhirnya terlihat, persis seperti compounding error yang dibahas di Part 1.

Ringkasan

• Agent di production adalah sistem terdistribusi dengan empat komponen inti — planner, tool use, memory, dan observation — bukan satu prompt tunggal yang “kebetulan pintar”
• Planner menerjemahkan tujuan jadi langkah konkret; plan dinamis yang bisa direvisi berdasarkan temuan baru jauh lebih tangguh dibanding plan statis yang dipaksakan meski asumsinya sudah terbukti salah
• Tool use adalah “tangan” agent — tool perlu didesain dengan kontrak yang jelas, idempoten untuk efek samping, dan agent perlu memilih tool yang tepat (tidak lebih invasif dari yang dibutuhkan) untuk tiap situasi
• Memory bukan satu mekanisme tunggal, melainkan sistem berlapis: working memory (per sesi, terbatas ukurannya), persistent memory (lintas sesi, termasuk spec teknis dari series sebelumnya), dan episodic memory (catatan kejadian masa lalu)
• Observation menentukan apakah loop benar-benar belajar dari tindakannya — verifikasi dangkal (“tidak ada error” dianggap “berhasil”) adalah sumber kegagalan paling umum dan paling sulit dideteksi
• Spec teknis (ERD, kontrak API, acceptance criteria) mengalir ke arsitektur agent di dua titik: sebagai input awal untuk planner, dan sebagai rujukan verifikasi untuk observation
• Sub-agent dalam satu task bermanfaat untuk eksplorasi paralel independen dan menjaga context window agent utama tetap ringkas — berbeda skalanya dengan orkestrasi multi-agent penuh yang dibahas di Part 6
• Setiap komponen punya cara gagal sendiri-sendiri; mendiagnosis kegagalan per komponen lebih produktif daripada menyalahkan “kecerdasan AI” secara umum