Lima Lapisan Engineering AI Agent: Prompt, Context, Harness, Loop, dan Graph

AI agent jarang gagal karena satu kalimat prompt kurang cerdas. Ia lebih sering gagal karena membaca data yang salah, memilih tool yang terlalu luas, mengulang langkah tanpa batas, kehilangan posisi pekerjaan, atau mengeksekusi tindakan yang seharusnya menunggu persetujuan.

Contohnya dekat dengan operasi harian. Tim meminta agent menyiapkan laporan performa kampanye. Instruksinya sudah rinci. Agent tetap bisa mengambil periode yang salah, mencampur data dua klien, memanggil tool publikasi alih-alih tool draft, lalu menyatakan pekerjaan selesai tanpa memeriksa artifact. Mengedit prompt mungkin memperbaiki satu gejala. Sistemnya tetap rapuh.

Cara yang lebih berguna adalah membedah AI agent menjadi lima lapisan engineering:

1. Prompt menentukan instruksi.
2. Context menentukan apa yang dilihat model pada langkah itu.
3. Harness menyediakan lingkungan, tools, guardrails, observability, dan mekanisme pembuktian.
4. Loop mengatur iterasi, feedback, retry, dan kondisi berhenti.
5. Graph menentukan topologi pekerjaan: node, state, routing, handoff, parallel branch, dan approval.

Kelima lapisan ini bukan tangga kematangan yang harus dinaiki secara linear. Harness adalah shell operasional terluar. Graph dan loop berjalan di dalamnya. Setiap node di graph merakit context dan menjalankan prompt yang sesuai. Sebuah node juga bisa bersifat deterministik tanpa memanggil model sama sekali.

Itulah peta yang kami pakai di Rama Digital untuk memisahkan masalah. Kalau output salah format, periksa prompt dan schema. Kalau sumbernya salah, periksa context. Kalau agent tidak bisa melihat hasil kerja atau melampaui izin, periksa harness. Kalau ia terus mencoba, periksa loop. Kalau pekerjaan masuk jalur atau approver yang salah, periksa graph.

Definisi ringkas: mana istilah mapan, mana yang masih emerging

Prompt engineering adalah istilah mapan untuk menyusun instruksi agar model menghasilkan perilaku yang diinginkan. Dokumentasi OpenAI tentang prompt engineering masih memakai definisi tersebut dan menekankan role, instruksi, contoh, versioning, serta eval. Jadi prompt engineering tidak mati. Scope-nya menjadi lebih jelas.

Context engineering adalah istilah yang sedang menguat dan lebih luas daripada prompt engineering. Anthropic mendefinisikannya sebagai strategi mengkurasi dan menjaga set token optimal saat inference, termasuk system instruction, tools, data eksternal, message history, dan informasi lain yang masuk ke context window. Konsep context window sendiri mapan; label context engineering masih berkembang.

Harness engineering adalah istilah emerging. Belum ada satu standar lintas vendor yang menetapkan batas resminya. OpenAI memakai istilah tersebut untuk pekerjaan membangun environment, scaffolding, tooling, feedback loop, dokumentasi, observability, dan constraint agar coding agent dapat bekerja andal. Dalam artikel ini kami memakai definisi operasional yang lebih umum: seluruh shell yang membuat agent dapat mengamati, bertindak, dibatasi, diuji, dan membuktikan hasil.

Loop adalah konsep mapan dalam software dan control flow. Istilah loop engineering untuk AI agent masih emerging: fokusnya bukan sekadar menjalankan model berkali-kali, tetapi mengatur progress, feedback, retry, budget, dan termination.

Graph-based workflow juga memakai konsep mapan dari computer science. Untuk AI agent, graph adalah pola implementasi yang sudah tersedia di framework seperti LangGraph dan Google Agent Development Kit. Graph bukan kewajiban. Ia berguna ketika routing, state, parallel branch, approval, atau pemulihan sudah terlalu kompleks untuk satu loop sederhana.

Perbedaan status ini penting. Kita tidak perlu memperlakukan setiap istilah baru sebagai disiplin terpisah atau membeli tool khusus untuk masing-masing. Yang dibutuhkan adalah pembagian tanggung jawab yang bisa diuji.

Peta non-linear: harness di luar, graph dan loop di dalam

Bayangkan sistem agent sebagai sebuah fasilitas kerja, bukan tumpukan lima kotak.

Harness membentuk batas fasilitas: filesystem atau workspace, tool registry, credential boundary, sandbox, policy, log, trace, eval runner, checkpoint storage, dan approval interface. Di dalam fasilitas itu ada graph yang menggambarkan jalur kerja. Beberapa bagian graph berbentuk linear; bagian lain bercabang atau berjalan paralel.

Satu node di graph dapat menjalankan loop. Contohnya node draft_article mengulang siklus tulis, lint, dan revisi maksimal tiga kali sampai pemeriksaan struktur lulus. Sebaliknya, sebuah loop dapat berpindah di antara beberapa node: model memilih tool, tool memperbarui state, validator memutuskan kembali ke model atau keluar.

Saat sebuah node memanggil model, context builder memilih informasi yang perlu dilihat: instruksi node, state aktif, sumber yang relevan, tool schema, hasil langkah terakhir, dan batas output. Prompt memberi tahu model apa yang harus dilakukan terhadap context tersebut.

Karena relasinya non-linear, kalimat "kami sudah pindah dari prompt engineering ke context engineering" terlalu menyederhanakan masalah. Context tanpa instruksi tetap tidak memberi tujuan. Prompt tanpa context tidak punya fakta yang cukup. Keduanya tidak menyediakan tool, permission, retry policy, atau bukti bahwa action benar-benar berhasil.

Peta ini juga menjelaskan kenapa model yang lebih kuat tidak otomatis memperbaiki sistem. Model dapat meningkatkan kualitas keputusan pada node tertentu. Model tidak akan menciptakan idempotency key di API, memperbaiki scope database yang bocor, atau memasang approval gate yang tidak ada.

Lapisan 1: prompt adalah kontrak instruksi

Prompt menjawab pertanyaan: apa tugas model pada panggilan ini, batasnya apa, dan bentuk hasil yang diterima seperti apa?

Untuk agent production, prompt sebaiknya lebih dekat dengan kontrak kerja daripada briefing motivasional. Isi minimumnya biasanya mencakup:

• tujuan node;
• authority dan larangan;
• definisi input yang diterima;
• panduan memilih tool;
• output contract;
• acceptance criteria;
• contoh canonical bila perilaku sulit dijelaskan hanya dengan aturan.

Misalnya, prompt node analisis kampanye tidak cukup berbunyi "analisis data iklan secara mendalam". Instruksi yang operasional menyebut periode, unit analisis, cara menangani data kosong, larangan mengarang penyebab, format temuan, dan kondisi ketika agent harus meminta data tambahan.

Prompt juga harus mengikuti struktur otoritas platform. Dokumentasi OpenAI membedakan instruksi aplikasi pada role berotoritas lebih tinggi dari input user. Secara praktis, policy bisnis tidak boleh ditempel sebagai bagian dari dokumen user yang kedudukannya ambigu.

Namun prompt bukan tempat menulis seluruh program. Jika syarat budget > batas selalu membutuhkan approval, letakkan aturan itu di code atau graph routing. Jangan berharap satu kalimat "selalu berhati-hati" bekerja sebagai access control.

Versikan prompt bersama perubahan aplikasi. Tambahkan fixture dan eval sebelum mengganti prompt production. Artikel Prompt Engineering 2026: Dari Instruksi ke Tool Schema, Eval, dan Acceptance Criteria membahas lapisan ini secara khusus.

Lapisan 2: context adalah apa yang benar-benar dilihat model

Context bukan sinonim prompt. Context mencakup semua token yang tersedia saat inference: instruksi, user input, tool definition, hasil retrieval, state yang diproyeksikan, message history, contoh, dan hasil tool sebelumnya.

Masalah context muncul dalam dua bentuk yang berlawanan.

Pertama, context kurang. Agent diminta merevisi proposal tetapi tidak melihat feedback terbaru, rate card aktif, atau identitas klien. Ia mengisi kekosongan dengan pola umum.

Kedua, context terlalu penuh atau salah scope. Agent menerima seluruh histori, versi dokumen lama, output tool mentah, dan data beberapa klien. Informasi penting ada, tetapi bersaing dengan noise dan konflik.

Anthropic menyarankan target yang tajam: set token sekecil mungkin dengan signal setinggi mungkin untuk menghasilkan perilaku yang diinginkan. Itu bukan berarti prompt harus selalu pendek. Artinya setiap item perlu punya alasan untuk masuk.

Di Rama Digital, context builder idealnya melakukan beberapa hal sebelum model dipanggil:

1. menerapkan tenant dan permission filter;
2. mengambil state task aktif, bukan seluruh chat;
3. memilih source of truth terbaru;
4. menyertakan provenance atau tautan sumber;
5. membuang hasil tool yang sudah tidak diperlukan;
6. menyisakan ruang untuk action berikutnya;
7. memakai progressive disclosure untuk data besar.

Pemisahan context, state, dan memory dibahas lebih detail di Context vs State vs Memory pada AI Agent. Untuk desain memory lintas pekerjaan, baca Apa Itu Second Brain dalam Dunia Agentic AI? dan Arsitektur Agentic Second Brain.

Keputusan pentingnya: data yang diketahui agent tidak otomatis menjadi izin untuk bertindak. Context memberi pengetahuan. Harness dan graph menentukan authority.

Lapisan 3: harness adalah lingkungan kerja dan sistem bukti

Harness menjawab pertanyaan: di mana agent bekerja, apa yang dapat disentuh, bagaimana hasil diamati, dan bukti apa yang harus ada sebelum status selesai?

Komponennya dapat mencakup:

• runtime dan sandbox;
• tools dengan schema yang jelas;
• akses file, browser, database, atau API;
• permission boundary dan secret handling;
• repository map dan dokumentasi yang dapat ditemukan;
• linter, unit test, eval, build, atau preview;
• log, metric, trace, screenshot, dan artifact;
• checkpoint serta recovery;
• approval mechanism;
• batas waktu, biaya, dan concurrency.

OpenAI menjelaskan bagaimana tim internalnya membuat aplikasi, log, metric, dan browser legible bagi Codex. Mereka juga menjadikan repository knowledge sebagai system of record, memakai dokumen ringkas sebagai peta alih-alih manual raksasa, lalu menegakkan invariant dengan linter dan structural test. Itu laporan kasus dari satu lingkungan software, bukan bukti bahwa angka throughput atau desainnya akan berlaku di organisasi lain.

Pattern industri yang dapat diambil lebih luas adalah ini: agent hanya bisa bertindak atas lingkungan yang dapat diakses, dan reliability naik ketika aturan penting dapat diperiksa secara mekanis.

Rekomendasi Rama Digital: definisi selesai harus selalu menunjuk bukti. "Artikel selesai" berarti file ada, H1 satu, referensi valid, lint bersih, dan status masih draft. "Deploy selesai" berarti release aktif dan health check lulus. Pernyataan agent bukan bukti environment.

Pembahasan khususnya ada di Harness Engineering untuk AI Agent.

Lapisan 4: loop mengelola iterasi dan kondisi berhenti

Tool-calling agent bekerja secara iteratif. Model melihat state dan context, memilih action, menerima hasil tool, lalu memutuskan langkah berikutnya. Dokumentasi OpenAI function calling menggambarkan alur request, tool call, eksekusi oleh aplikasi, pengembalian tool output, lalu respons atau tool call berikutnya.

Tanpa desain loop, iterasi berubah menjadi risiko:

• tool yang sama dipanggil berulang dengan argumen sama;
• error permanen diperlakukan seperti error sementara;
• output direvisi tanpa meningkatkan skor apa pun;
• action eksternal terduplikasi setelah timeout;
• agent berhenti karena kuota habis, bukan karena tugas selesai;
• status "selesai" muncul tanpa verifikasi.

Loop yang sehat membutuhkan state kemajuan, termination condition, budget, retry classification, dan escalation path. Minimal tetapkan max_steps, max_elapsed_time, batas biaya, dan batas retry per tool. Lebih penting lagi, tetapkan kondisi semantik: acceptance criteria lulus, tidak ada blocker, artifact terverifikasi, atau human memutuskan berhenti.

Retry hanya aman bila efek samping dipahami. Operasi write perlu idempotency key, reconciliation, atau pemeriksaan environment sebelum diulang. Kalau email mungkin sudah terkirim tetapi respons API timeout, langkah berikutnya bukan otomatis send_email lagi.

Google ADK mendokumentasikan Loop Agent sebagai workflow yang mengulang sub-agent sampai termination condition tertentu. Itu menyediakan primitive. Tim tetap harus menentukan kondisi berhenti dan bukti progress yang cocok dengan pekerjaannya.

Desain rinci tersedia di Loop Engineering: Mendesain AI Agent Tanpa Infinite Loop. Untuk contoh loop coding yang lebih praktis, lihat Claude Code Loop untuk Workflow Koding Sehari-hari.

Lapisan 5: graph mengatur topologi dan control flow

Graph menjawab: langkah apa yang ada, state apa yang berpindah, jalur mana yang dipilih, siapa menerima handoff, dan di mana pekerjaan harus berhenti?

Dalam dokumentasi LangGraph, tiga komponen dasarnya adalah state, nodes, dan edges. Node melakukan pekerjaan; edge menentukan node berikutnya. Node bisa berisi LLM, code biasa, atau side effect. Framework tersebut juga mendukung persistence dan human-in-the-loop untuk workflow yang berjalan lama.

Google ADK membedakan sequential, parallel, dan loop workflow yang deterministik. Dokumentasinya juga menunjukkan pergeseran ke graph-based dan dynamic workflows untuk kontrol yang lebih fleksibel. Fakta ini menunjukkan ketersediaan primitive, bukan kewajiban memilih salah satu framework.

Graph dibutuhkan ketika proses mempunyai salah satu ciri berikut:

• beberapa jenis input harus dirutekan berbeda;
• ada parallel work yang harus digabung;
• state perlu dipulihkan setelah pause;
• action sensitif menunggu approval;
• ada handoff antara fungsi atau agent;
• jalur koreksi berbeda dari retry teknis;
• audit membutuhkan rekam transisi yang eksplisit.

Jangan mengubah flow tiga langkah menjadi diagram dua puluh node hanya karena graph terlihat rapi. Mulai dengan code linear. Naikkan ke graph saat branching dan lifecycle state sudah memberi nilai nyata.

Pembahasannya ada di Graph-Based Agent Workflow: Nodes, State, Routing, Handoff, dan Approval.

Satu contoh utuh: laporan performa klien

Kita gunakan satu workflow yang cukup nyata: menyiapkan laporan performa iklan bulanan untuk klien, lalu meminta persetujuan sebelum laporan dikirim.

Prompt pada setiap node

Node extract_metrics menerima instruksi untuk mengekstrak field tertentu, menandai data kosong, dan tidak membuat interpretasi. Node analyze_variance membandingkan periode dengan baseline yang sudah ditentukan. Node write_summary mengubah temuan terverifikasi menjadi bahasa klien. Tiga node memakai prompt berbeda karena tujuan dan acceptance criteria-nya berbeda.

Context yang diproyeksikan

extract_metrics melihat client ID, periode, mapping akun, dan schema metrik. Ia tidak membutuhkan histori komunikasi klien. write_summary melihat temuan terstruktur, tone guide, keputusan rapat yang masih berlaku, dan batas klaim. Ia tidak perlu menerima raw export penuh.

Harness yang membatasi dan membuktikan

Tool data hanya dapat membaca akun sesuai tenant. Workspace terisolasi per run. Validator memeriksa periode dan currency. Laporan dirender ke preview. Log menyimpan sumber, query, tool call, versi prompt, serta hasil gate. Tool kirim tidak tersedia sampai approval.

Loop yang mengatur revisi

Jika validator menemukan field wajib kosong, agent boleh memperbaiki query maksimal dua kali. Jika sumber tetap kosong, status berubah menjadi blocked_data, bukan loop tanpa batas. Draft summary boleh direvisi sampai semua aturan struktural lulus atau budget habis. Setiap iterasi harus mencatat failure baru yang sedang diperbaiki.

Graph yang mengatur jalur

Flow-nya dapat ditulis seperti ini:

START
 -> validate_request
 -> fetch_data
 -> validate_data
 -> [invalid] repair_or_block
 -> [valid] analyze
 -> write_draft
 -> quality_gate
 -> [fail] revise_draft
 -> [pass] human_approval
 -> [rejected] revise_draft
 -> [approved] send_report
 -> verify_delivery
 -> END

human_approval bukan tulisan di prompt. Ia node yang benar-benar menghentikan execution. send_report tidak dianggap sukses hanya karena API menerima request; verify_delivery memeriksa hasil yang dapat diamati.

Inilah keuntungan peta lima lapisan: setiap failure punya alamat.

Failure modes dan lapisan yang harus diperbaiki

"Agent tidak mengikuti format"

Periksa prompt, output schema, dan validator. Jika format bersifat machine-readable, gunakan structured output atau parser ketat daripada instruksi prosa berulang.

"Agent memakai dokumen lama"

Ini masalah context retrieval, metadata, authority, atau source-of-truth policy. Menambah kalimat "gunakan data terbaru" tidak memperbaiki indeks tanpa tanggal berlaku.

"Agent tidak tahu file atau dashboard mana yang harus dibuka"

Periksa harness legibility: repository map, naming, tool discovery, dokumentasi, dan akses. Informasi yang tidak bisa ditemukan praktis tidak ada bagi agent.

"Agent mengulang tool yang sama"

Periksa loop state, stall detection, retry classification, dan termination. Catat signature tool call agar pengulangan identik dapat dihentikan.

"Agent mengirim sebelum disetujui"

Periksa graph dan permission. Approval harus menjadi kontrol runtime, bukan permintaan sopan dalam prompt.

"Agent salah handoff"

Periksa routing rule, state contract, dan eval handoff. OpenAI dalam panduan evaluation best practices membedakan evaluasi instruction following, tool selection, argument precision, dan handoff accuracy. Memakai satu skor kualitas jawaban akan menutupi lokasi failure.

"Agent bilang selesai, tetapi hasil tidak ada"

Periksa proof layer di harness. Tambahkan postcondition: file exists, record status berubah, URL dapat diakses, test lulus, atau penerima tercatat. Completion harus berasal dari pemeriksaan, bukan confidence model.

Praktik Rama Digital: fakta, pattern, rekomendasi

Agar pembahasan vendor tidak berubah menjadi klaim universal, kami membedakan tiga kategori.

Fakta sumber resmi: dokumentasi vendor menjelaskan fitur atau desain tertentu. Contohnya, LangGraph mendokumentasikan persistence dan interrupt; Google ADK mendokumentasikan sequential, parallel, serta loop workflow; OpenAI mendokumentasikan tool calling dan eval. Fakta ini berlaku pada produk atau panduan yang disebut.

Pattern industri: beberapa implementasi menunjukkan arah yang sama, misalnya progressive disclosure, tool schema, checkpoint, observability, eval-driven development, dan human approval. Pattern ini layak diuji, tetapi belum otomatis menjadi standar wajib.

Rekomendasi Rama Digital: mulai dari workflow sempit, buat boundary deterministic, wajibkan bukti sebelum selesai, dan naikkan otonomi berdasarkan trace serta eval. Ini keputusan desain kami, bukan hasil ilmiah yang berlaku di semua perusahaan.

Pemisahan ini mencegah dua kesalahan: menyalin arsitektur vendor tanpa konteks, dan menyebut opini internal sebagai fakta teknologi.

Urutan implementasi yang lebih aman

1. Pilih satu outcome operasional

Jangan mulai dari "buat agent perusahaan". Pilih satu hasil: laporan siap review, tiket terklasifikasi, proposal terisi, atau bug terverifikasi. Tentukan siapa owner dan siapa yang menerima hasil.

2. Buat baseline manual dan acceptance criteria

Catat waktu, koreksi, failure, serta approval yang terjadi pada proses sekarang. Tulis syarat selesai yang dapat diperiksa. Tanpa baseline, tim hanya membandingkan kesan demo.

3. Mulai dengan flow deterministic sejauh mungkin

Parsing tanggal, permission check, threshold nominal, dan format schema tidak membutuhkan kebebasan model. Pakai model untuk bagian yang memang membutuhkan interpretasi.

4. Pisahkan prompt per tanggung jawab

Satu prompt besar sulit diuji. Berikan setiap model call tujuan sempit, input contract, output contract, dan eval cases.

5. Bangun context projection

Tentukan informasi wajib, opsional, dan terlarang pada tiap node. Terapkan scope sebelum retrieval. Simpan pointer ke source of truth, bukan menyalin semua data ke memory.

6. Sediakan harness minimum

Berikan tools yang tidak overlap, sandbox atau workspace yang jelas, log, artifact, validator, dan approval untuk write berisiko. Jangan memberi tool publish hanya karena nanti "mungkin diperlukan".

7. Tambahkan loop budget dan recovery

Definisikan progress, retryable error, non-retryable error, max steps, timeout, dan escalation. Uji interruption tepat setelah side effect untuk melihat apakah action terduplikasi.

8. Formalisasikan graph bila branching tumbuh

Saat condition, parallel work, pause, dan handoff bertambah, pindahkan control flow ke graph yang dapat ditelusuri. Jaga state schema tetap kecil dan eksplisit.

9. Evaluasi per lapisan

Pisahkan eval prompt adherence, context precision, tool selection, argument accuracy, route accuracy, termination, approval compliance, dan proof of completion. Satu nilai rata-rata tidak cukup untuk debugging.

10. Naikkan otonomi secara bertahap

Urutannya dapat dimulai dari read, analyze, draft, propose action, approved write, lalu bounded autonomous write. Hak akses mengikuti bukti reliability dan dampak salah, bukan antusiasme tim.

Checklist audit lima lapisan

Prompt

• Apakah setiap model call punya satu tujuan yang jelas?
• Apakah input, output, larangan, dan acceptance criteria eksplisit?
• Apakah prompt berversi dan punya fixture serta eval?
• Apakah aturan deterministic sudah dipindah ke code atau policy?

Context

• Informasi apa yang dilihat model pada node ini?
• Apakah tenant, permission, recency, dan authority sudah difilter?
• Apakah source of truth dapat ditelusuri?
• Apakah tool output lama dibuang atau diringkas?

Harness

• Tool apa yang tersedia, dan apakah fungsinya overlap?
• Apakah workspace, credential, dan data terisolasi?
• Bukti apa yang wajib ada sebelum status selesai?
• Apakah log, trace, test, preview, dan approval dapat diakses?

Loop

• Apa indikator progress pada tiap iterasi?
• Kapan retry diizinkan, dihentikan, atau dieskalasi?
• Apakah side effect idempotent atau dapat direkonsiliasi?
• Apa batas step, waktu, biaya, dan pengulangan identik?

Graph

• Apakah state schema menunjukkan posisi kerja yang sebenarnya?
• Apakah routing penting deterministic atau teruji?
• Di mana approval menghentikan execution?
• Apakah handoff membawa context minimum dan owner yang jelas?
• Dapatkah workflow dipulihkan setelah pause atau crash?

Keputusan akhirnya: jangan optimasi lapisan yang salah

Prompt yang baik tetap penting. Tetapi prompt hanya satu kontrak instruksi di dalam sistem yang lebih besar. Context menentukan bahan yang tersedia. Harness menentukan ruang kerja, kemampuan, batas, dan bukti. Loop menentukan cara agent mencoba serta berhenti. Graph menentukan ke mana pekerjaan bergerak.

Mulai audit dari failure yang terlihat, lalu cari lapisannya. Jangan menambah prompt ketika masalahnya permission. Jangan mengganti model ketika masalahnya dokumen basi. Jangan menambah agent ketika flow tiga langkah belum punya acceptance criteria.

Kalau lima lapisan ini dipisahkan dengan jelas, engineering AI agent menjadi lebih membosankan dalam arti yang baik: masalah bisa dilokalisasi, diuji, diperbaiki, dan diputuskan secara operasional.