Ketika Anthropic menerbitkan Building Effective Agents pada akhir 2024, ia melakukan sesuatu yang langka bagi industri ini: memberikan kosakata bersama bagi para insinyur. Alih-alih manifesto lain tentang kecerdasan umum buatan (AGI), panduan tersebut menawarkan enam pola jelas untuk menyusun sistem LLM. Satu setengah tahun kemudian, pada tahun 2026, lanskapnya tampak sangat berbeda. Model Context Protocol telah menjadi standar universal. Claude telah memperoleh kemampuan baru. Sebagian besar organisasi kini memiliki setidaknya satu agen yang berjalan di produksi. Dengan latar belakang tersebut, wajar jika muncul pertanyaan apakah keenam pola tersebut masih relevan, atau apakah mereka sudah layak masuk ke arsip di samping bobot model tahun lalu.

Saya menguji keenam pola tersebut terhadap model lokal di repositori terpisah untuk mengetahuinya. Jawabannya adalah ya. Pola-pola tersebut masih bertahan. Namun bukan karena mereka adalah hukum yang tidak dapat diubah. Mereka bertahan karena pengalaman produksi selama delapan belas bulan terakhir telah memvalidasi logika inti dari kerangka kerja tersebut.

Apa yang Sebenarnya Diberikan Kerangka Kerja Ini kepada Kita

Keenam pola tersebut sangat layak untuk diingat: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, dan Autonomous Agents. Yang terakhir pada dasarnya adalah sebuah loop di mana model merencanakan, bertindak, mengamati, dan mengulanginya hingga suatu kondisi terpenuhi.

Banyak insinyur yang sudah melakukan chaining prompt atau mendelegasikan tugas ke worker thread sebelum panduan tersebut muncul. Apa yang disediakan Anthropic adalah taksonomi. Apa yang disebut "agent" oleh satu orang adalah "workflow" bagi orang lain, dan "multi-step tool call" bagi orang ketiga. Panduan tersebut merapikan kekacauan tersebut ke dalam kategori-kategori dengan batasan yang jelas. Hal ini memungkinkan adanya diskusi mengenai trade-off tanpa saling salah paham. Di bidang yang tenggelam dalam hype, bahasa yang lugas adalah sejenis infrastruktur.

Industri Membangun di Atasnya, Bukan di Sekitarnya

Pada tahun 2026, kategori-kategori ini telah menyatu ke dalam cara tim merancang sistem. Anthropic masih mengajarkannya dalam kursus Academy mereka. Makalah penelitian dan blog teknik masih menggunakan enam kategori yang sama untuk mendeskripsikan arsitektur baru. Umur panjang semacam itu tidaklah biasa bagi disiplin ilmu yang memperbarui stack-nya setiap kuartal.

Alasannya sederhana. Industri tidak mengganti kerangka kerja tersebut. Industri membangun di atasnya. Alat-alat baru seperti MCP dan standar Agent Skills yang lebih baru berfungsi sebagai perpipaan (plumbing). Mereka memudahkan untuk menghubungkan model ke database, mengekspos alat, atau mengelola state. Namun, mereka tidak mengubah logika tentang kapan harus menggunakan router alih-alih orchestrator. Pipa yang lebih baik tidak menulis ulang denah lantai.

Data produksi pada tahun 2026 mengonfirmasi hal ini. Pola penerapan yang paling umum masih berupa satu panggilan penggunaan alat (tool-use call) yang dipasangkan dengan tinjauan manusia. Yang kedua paling umum adalah workflow multi-langkah dengan tepat satu penyerahan (handoff) kepada manusia. Keduanya adalah keturunan langsung dari Prompt Chaining dan Routing. Loop otonom penuh tetap menjadi pengecualian, bukan aturan, dalam sistem yang berjalan langsung (live systems).

Pengendalian Diri Memenangkan Pasar

Saran terbaik dari panduan asli tersebut juga merupakan saran yang paling sering diabaikan pada tahun 2024: gunakan pola paling sederhana yang berhasil. Jangan menerapkan agen otonom penuh jika jalur hardcoded dapat menyelesaikan pekerjaan tersebut.

Pasar akhirnya menginternalisasi hal ini. Sebagian besar uji coba (pilot) agen masih gagal, dan mereka gagal karena alasan yang sama dan dapat diprediksi. Tim menumpuk abstraksi di atas abstraksi hingga tidak ada yang bisa melacak batas keputusan. Ketika sistem melenceng, debugging menjadi seperti arkeologi. Perusahaan yang telah berhasil dalam produksi adalah mereka yang menunjukkan pengendalian diri. Mereka menggunakan penggunaan alat satu putaran (single-turn tool use) sebagai standar. Mereka menambahkan lapisan routing hanya setelah prompt tunggal terbukti tidak konsisten. Mereka memperlakukan otonomi sebagai liabilitas yang harus dijustifikasi, bukan fitur yang harus dirayakan.

Ini bukan argumen melawan ambisi. Ini adalah argumen untuk komposisi. Pola-pola tersebut bekerja paling baik ketika Anda menggabungkannya secara sengaja, alih-alih secara refleks memilih opsi paling kompleks dalam menu.

Di Mana Celah Mulai Terlihat

Kerangka kerja ini bukanlah obat untuk segalanya. Ada batasan keras yang muncul saat Anda meninggalkan tahap prototipe.

Untuk tugas-tugas berfrekuensi tinggi dan berbiaya rendah, kode deterministik tetap menjadi pemenang. Sebuah LLM tidak seharusnya melakukan normalisasi kolom CSV ketika pandas dapat melakukannya dalam hitungan milidetik tanpa berhalusinasi. Hindari loop otonom jika Anda tidak dapat menentukan tujuan evaluasi yang jelas. Tanpa kondisi penghentian yang jelas, model akan terus beriterasi hingga ia menciptakan alasan untuk berhenti. Untuk keputusan berisiko tinggi yang memerlukan landasan eksternal, jangan hanya mengandalkan pengetahuan internal model. Dan perhatikan hambatan dalam pengambilan data. Pola apa pun yang bergantung pada pencarian vektor atau API eksternal dapat tersendat jika database Anda lambat atau jendela konteks Anda tersumbat oleh potongan data yang tidak relevan.

Ini bukanlah kasus ekstrem hipotetis. Ini adalah batasan yang membedakan demo yang berfungsi dengan sistem yang mampu bertahan melewati akhir pekan.

Pemeriksaan yang Kaku dan Kegagalan yang Salah

Saya mempelajari nilai praktis dari kerangka kerja ini saat membangun repositori pengujian saya. Saya sedang menerapkan pola Evaluator-Optimizer. Evaluator saya dimulai sebagai regex yang dikodekan secara keras (hardcoded) yang memindai output model untuk kata kunci tertentu. Model memberikan jawaban yang benar dan beralasan, namun kebetulan menggunakan sinonim alih-alih kata-kata tepat yang saya cari. Evaluator menandainya sebagai kegagalan.

Model tersebut benar. Pemeriksaan saya terlalu kaku.

Memperbaikinya membutuhkan lebih dari sekadar memperluas daftar kata. Saya mengubah evaluator itu sendiri menjadi penilaian berbasis LLM. Hal itu memakan biaya token tambahan dan beberapa milidetik lebih lama, tetapi mengembalikan evaluasi ke tingkat abstraksi yang tepat. Pola itu sendiri sudah benar. Saya hanya memilih implementasi yang salah untuk tugas tersebut. Itulah tepatnya jenis kesalahan yang ingin dicegah oleh kerangka kerja ini. Beberapa evaluasi membutuhkan kode. Yang lain membutuhkan model. Mengetahui mana yang mana adalah inti dari semuanya.

Cara Menggunakannya Sekarang

Perlakukan keenam pola ini sebagai titik awal, bukan hukum mutlak. Mulailah dengan satu prompt tunggal. Jika kualitas tidak konsisten di berbagai jenis input, tambahkan lapisan perutean (routing layer) untuk mengirim permintaan yang berbeda ke prompt khusus. Jika Anda memerlukan beberapa perspektif independen sebelum mengambil keputusan, gunakan Parallelization. Jika tugasnya besar dan dapat dibagi, cobalah Orchestrator-Workers. Gunakan loop otonom penuh hanya ketika ruang masalah terlalu luas untuk dipetakan sebelumnya dan ketika Anda memiliki yang andal