Dunia AI berkembang pesat, dan dengan itu muncul istilah-istilah baru yang bisa jadi membingungkan. Tiga istilah yang kini sering muncul dalam deskripsi pekerjaan rekayasa AI adalah Prompt Engineering, Loop Engineering, dan Graph Engineering. Jangan bingung, ketiganya bukan teknik yang saling bersaing. Justru, mereka adalah tiga lapisan yang berbeda dan saling bertumpuk, layaknya sebuah kue lapis.
Bayangkan seperti ini: Prompt Engineering mengontrol satu respons model. Loop Engineering mengatur siklus perilaku satu agen. Sedangkan Graph Engineering mengendalikan organisasi dari banyak agen. Setiap lapisan di atas mempertahankan lapisan di bawahnya. Jadi, sebuah prompt tidak akan hilang ketika sebuah loop dibangun di sekitarnya. Itu hanya tidak lagi menjadi sesuatu yang kamu ketik secara manual.
Artikel ini akan membedah ketiganya: apa yang dirancang di setiap lapisan, kapan lapisan yang lebih tinggi benar-benar diperlukan, dan mengapa ada sedikit keraguan. Penting juga untuk diingat, setiap langkah dalam perkembangan ini diberi nama dalam praktik sebelum muncul dalam dokumentasi resmi.
Prompt Engineering: Mengendalikan Satu Respon
Prompt Engineering adalah lapisan dasar. Ini fokus pada cara kamu menulis dan menyusun instruksi untuk satu panggilan model. Tujuannya adalah memisahkan system prompt menjadi bagian-bagian berlabel, seperti informasi latar belakang, instruksi, panduan tool, dan deskripsi output, yang bisa ditandai dengan tag XML atau header Markdown. Rekomendasinya adalah memberikan informasi seminimal mungkin, tetapi tetap lengkap untuk menentukan perilaku yang diharapkan. Minimal di sini bukan berarti pendek, ya.
Kemudian muncullah context engineering, yang disebut Anthropic sebagai perkembangan alami dari prompt engineering. Pertanyaannya bergeser dari menemukan kata-kata yang tepat menjadi memutuskan konfigurasi token apa yang harus ada di dalam window konteks sama sekali. Konteks adalah sumber daya terbatas, dan masalah tekniknya adalah mengoptimalkan utilitas token tersebut terhadap batasan model.
Asumsi utama di lapisan prompt adalah bahwa ada manusia yang hadir di setiap iterasi. Kamu menulis prompt, model merespons, output dinilai, lalu prompt direvisi.
Asumsi ini akan rusak jika menghadapi situasi seperti: volume tinggi, tugas multi-langkah, tidak ada manusia yang tersedia untuk menilai output, atau hasil yang otomatis menjadi input untuk langkah selanjutnya. Di kondisi seperti ini, prompt saja tidak lagi cukup.
Tapi ingat, prompt engineering tidak hilang di lapisan yang lebih tinggi. Riset multi-agen Anthropic bahkan melaporkan bahwa prompt engineering adalah kunci untuk memperbaiki kegagalan koordinasi. Versi awal sistem mereka melahirkan 50 sub-agent untuk query sederhana, dan solusinya adalah penyesuaian prompt, bukan perubahan topologi agen.
Loop Engineering: Mengatur Siklus Agen Tunggal
Loop Engineering datang berikutnya, sekitar akhir tahun 2025 dan mendominasi diskusi pengembang hingga Juni 2026. Ini adalah lapisan di atas prompt. Kamu sekarang merancang lingkungan tempat agen tunggal beroperasi, termasuk file, tools, memori, dan umpan balik.
Sebuah makalah arXiv pada Juni 2026 tentang AI agenik dalam rekayasa bangunan secara eksplisit menjelaskan progresi empat langkah yang sama: prompt, lalu context, lalu harness, lalu loop. Lapisan terakhir ini mendefinisikan bagaimana sistem secara berulang mengamati, bertindak, memverifikasi, dan memulihkan diri.
Kerangka berpikirnya adalah agen coding sebagai tool brute-force untuk menemukan solusi. Keahliannya adalah merancang tujuan, tools, dan loop, bukan hanya prompt itu sendiri. Tim Claude Code di Anthropic menjelaskan pergeseran yang sama ini di atas panggung.
Anthropic memecah loop engineering menjadi lima primitif, ditambah elemen keenam yang menyatukannya:
- Trigger: Sebuah jadwal atau peristiwa yang melakukan penemuan dan triage tanpa pengawasan.
- Workspace: Isolasi sehingga agen paralel tidak dapat mengedit file yang sama, dengan pengetahuan proyek ditulis sekali di dalam README.
- Tools: Plugin dan konektor untuk akses berbasis MCP ke issue tracker, database, atau API staging.
- Review: Pemisahan maker/checker, karena model yang menulis kode cenderung terlalu murah hati dalam menilainya.
- Memory: Sebuah file Markdown atau papan di luar percakapan, karena model lupa di antara eksekusi.
Dua fitur in-session sangat penting:
- Pulse: Berjalan kembali secara berkala (sesuai cadence).
- Goal Seeker: Berjalan sampai kondisi tertulis benar-benar terpenuhi, dengan model kecil terpisah yang memeriksa setelah setiap putaran. Jadi, agen yang menulis kode bukanlah agen yang menilainya.
Bagian sulitnya bukan siklusnya, melainkan kondisi berhenti-nya. Sebuah loop yang tidak bisa secara mekanis membedakan antara "selesai" dan "macet" tidak akan gagal dengan keras. Itu hanya akan terus menghabiskan token.
Graph Engineering: Mengorkestrasi Banyak Agen
Sekitar Juli 2026, diskusi bergerak dari loop ke graph. Jika loop membuat perilaku agen dapat diprogram, maka graph membuat organisasi agen dapat diprogram. Ini adalah label terbaru dan paling belum mapan.
Satu tulisan perusahaan mencatat bahwa asal istilah ini belum terpecahkan dan bertabrakan dengan penggunaan "knowledge-graph" yang lebih tua. Praktik dasarnya, yaitu orkestrasi berbasis graph, memiliki silsilah yang terdokumentasi dalam riset sistem multi-agen.
Poin struktural yang sering terlewatkan adalah bahwa sistem multi-agen produksi menjalankan dua graph secara bersamaan:
- Org Graph: Ini adalah graph yang stabil. Agen yang berumur panjang memiliki peran yang ditentukan, menguasai zona tertentu, dan mengumpulkan konteks seiring waktu. Ini berubah saat redeploy. Org graph menjawab pertanyaan "siapa melakukan apa?".
- Work Graph: Ini adalah graph yang ephemeral (berumur pendek). Node tugas hanya ada selama pekerjaan berlangsung. Edge akan terpecah untuk jalur paralel, bergabung saat konvergensi, dan hilang ketika bukti membuat suatu cabang tidak diperlukan. Work graph menjawab pertanyaan "bagaimana pekerjaan diselesaikan?".
Skeptisisme di sekitar label ini cukup beralasan. Sub-agent dengan tujuan yang jelas sudah membentuk graph, dan teknologi ini mendahului kosa katanya. LangChain bahkan mengirimkan API graph-nya jauh sebelum istilah ini ada. Lima pola alur kerja Anthropic dari Desember 2024, seperti prompt chaining, routing, parallelization, orchestrator-workers, dan evaluator-optimizer, pada dasarnya adalah topologi graph yang dijelaskan secara narasi. Yang baru adalah nama yang disepakati untuk keputusan-keputusan yang selalu dipaksakan oleh framework tersebut: apa node-nya, apa edge-nya, apa yang ada di state-nya.
Artefak konkretnya patut diketahui. Dalam LangGraph, sebuah state schema dideklarasikan. Node mendaftar dengan add_conditional_edges yang ditandai, lalu graph dikompilasi. Node adalah fungsi biasa yang menerima state dan mengembalikan pembaruan parsial. Konteks tidak melewati batas node kecuali jika sebuah edge membawanya, dan itulah yang menjelaskan mode kegagalannya.
Bagaimana Memilih Lapisan yang Tepat?
Untuk menentukan lapisan mana yang kamu butuhkan, jawablah pertanyaan-pertanyaan berikut secara berurutan. Jawaban "tidak" yang pertama biasanya adalah jawabannya.
| Pertanyaan Penentu | Jika Ya, Maka... | Jika Tidak, Maka... |
|---|---|---|
| Apakah manusia membaca setiap output sebelum sistem bertindak? | Lapisan Prompt cukup. Loop memberikan eksekusi tanpa pengawasan, bukan otonomi. | Lanjutkan ke pertanyaan berikutnya. |
| Bisakah kondisi "selesai" diperiksa oleh selain manusia? | Lanjutkan ke pertanyaan berikutnya. | Jika tidak, tidak ada kondisi berhenti. Sistem akan berjalan sampai anggaran token habis, bukan karena selesai. |
| Apakah tugas tersebut sesuai dalam satu konteks agen dan satu domain? | Bangun Loop. Satu alur penalaran adalah cara termurah untuk menjaga konsistensi asumsi. | Lanjutkan ke pertanyaan berikutnya. |
| Apakah ada cabang independen yang perlu berjalan secara bersamaan? | Ini masalah Graph. Deklarasikan nodes, edges, state bersama, dan rute kegagalan. | Perluas tools yang ada di Loop sebelum menambahkan agen baru. |
Hubungan Antar Lapisan dan Peringatan Penting
Makalah arXiv Juli 2026 tentang coding-agent loops menyatakan hubungan ini dengan benar: sebuah loop adalah prompt yang diulang dengan scaffolding di sekitarnya. Loop engineering bersifat komplementer terhadap prompt engineering, bukan penggantinya. Hal yang sama berlaku satu lantai di atasnya. Graph dibangun dari loop, dan loop dibangun dari prompt.
Hati-hati, ada peringatan penting. Membangun lapisan yang lebih tinggi tidak selalu berarti lebih mudah. Dua engineer bisa membangun loop yang identik dan mendapatkan hasil yang berlawanan. Satu bergerak lebih cepat pada pekerjaan yang mereka pahami secara mendalam. Yang lain justru menghindari pemahaman pekerjaan sama sekali. Sistem tidak bisa membedakannya. Inilah yang membuat lapisan yang lebih tinggi lebih sulit dirancang daripada prompt, bukan lebih mudah.
Ingat, ini adalah tiga unit kontrol, bukan tiga metode yang bersaing:
- Sebuah prompt mengontrol satu respons.
- Sebuah loop mengontrol siklus satu agen.
- Sebuah graph mengontrol organisasi dari banyak agen.
Sebuah loop hanya sebagus kondisi berhentinya. Tanpa pemeriksaan mekanis untuk "selesai", sebuah eksekusi tanpa pengawasan akan berakhir karena anggaran token, bukan karena kebenaran.
Dalam produksi, dua graph berjalan secara bersamaan: sebuah org graph yang stabil (menjawab "siapa melakukan apa?"), dan sebuah work graph per tugas yang memecah, menggabungkan, dan membatalkan seiring datangnya bukti.
Data menunjukkan bahwa ada peningkatan +90.2% pada evaluasi riset internal, tetapi juga konsumsi token sekitar 15 kali lipat dari sebuah chat biasa. Pengeluaran token saja menjelaskan 80% varians tersebut.
Sebagian besar tugas tidak akan pernah mencapai puncak stack. Kasus pengecualiannya adalah pekerjaan yang banyak melibatkan penulisan, di mana keputusan yang tersebar menghasilkan asumsi yang saling bertentangan.
Referensi
https://www.marktechpost.com/2026/07/29/prompt-engineering-vs-loop-engineering-vs-graph-engineering/