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/

Pahami perbedaan dan hubungan antara Prompt Engineering, Loop Engineering, dan Graph Engineering sebagai tiga lapisan kontrol yang saling membangun dalam pengembangan sistem AI multi-agen.

Prompt Engineering vs Loop Engineering vs Graph Engineering: Memahami Perbedaan Tiap Lapisan Kontrol AI

Reggi

Solusi praktis integrasi webmail custom ke dalam dashboard Gmail. Kelola, baca, dan kirim email domain pribadi langsung dari satu tempat tanpa ribet gonta-ganti tab.

Mengapa Kamu Masih Buka Dua Tab Terpisah? Panduan Setup Custom Webmail Langsung di Dashboard Gmail

Pelajari efisiensi merakit mesin tetas telur listrik AC otomatis dengan modal murah untuk mendongkrak hasil ternak unggas tanpa repot bolak-balik telur manual.

Otomasi Ternak Unggas: Kenapa Rakit Sendiri Mesin Penetas Telur AC Jauh Lebih Worth It Dibanding Cara Konvensional?

Pelajari bagaimana mesin tetas telur berbasis arus listrik DC bekerja menjaga suhu dan kelembapan ideal untuk mendongkrak keberhasilan penetasan telur unggas.

Mesin Tetas Telur Arus DC: Solusi Hardware Murah Buat Tingkatin Angka Penetasan Unggas

Kupas tuntas seluk-beluk mobil aki anak dengan kontrol ganda dan fitur multimedia. Pahami batas spesifikasi hardware sebelum eksekusi build sendiri.

EV Versi Mini: Membedah Mobil Listrik Aki Lengkap dengan Remote Control dan Fitur Multimedia

Pelajari cara merakit smart power strip berbasis NodeMCU dan Blynk untuk kontrol daya nirkabel serta integrasi IoT yang aman dan efisien.

Mengapa Beli Mahal Kalau Bisa Bikin Sendiri? Rancang Smart Power Strip Berbasis NodeMCU dan Blynk

Solusi tuntas mengatasi bug sistem dan software bermasalah di MacBook dengan panduan install ulang macOS lewat Internet Recovery secara aman.

#multi-agent-systems

Getting Lastest Post..

Populer Bulan Ini