Judul asli: What to Learn, Build, and Skip in AI Agents (2026)
Penulis asli: Rohit
Diterjemahkan: Peggy, BlockBeats

Catatan editor: Bidang Agen AI sedang memasuki fase ledakan alat, kurangnya konsensus.

Setiap minggu muncul kerangka kerja baru, model baru, benchmark baru, dan produk «10 kali efisiensi» yang baru, tetapi pertanyaan yang benar-benar penting bukan lagi «bagaimana mengikuti semua perubahan», melainkan «perubahan mana yang benar-benar layak diinvestasikan».

Penulis berpendapat, di saat tumpukan teknologi terus ditulis ulang, yang benar-benar bisa memberi manfaat jangka panjang bukanlah mengikuti kerangka terbaru, melainkan kemampuan dasar yang lebih fundamental: rekayasa konteks, desain alat, sistem evaluasi, pola orchestrator-subagent, pemikiran sandbox dan harness. Kemampuan ini tidak akan cepat usang seiring pergantian model, malah akan menjadi fondasi membangun Agen AI yang andal.

Artikel ini bahkan lebih jauh menunjukkan bahwa Agen AI juga mengubah makna «kredensial». Dulu, gelar pendidikan, jabatan, dan pengalaman adalah tiket masuk ke industri; tetapi di bidang yang bahkan raksasa pun masih melakukan eksperimen terbuka, resume tidak lagi satu-satunya bukti. Apa yang kamu lakukan, apa yang kamu serahkan, menjadi semakin penting.

Oleh karena itu, artikel ini tidak hanya membahas apa yang harus dipelajari, digunakan, dan diabaikan di tahun 2026 dalam bidang Agen AI, tetapi juga mengingatkan: di era yang semakin bising ini, kemampuan yang paling langka adalah kemampuan untuk menilai apa yang layak dipelajari dan terus menghasilkan sesuatu yang benar-benar berguna.

Berikut adalah teks asli:

Setiap hari muncul kerangka kerja baru, benchmark baru, dan produk «10 kali efisiensi» yang baru. Masalahnya bukan lagi «bagaimana saya mengikuti», melainkan: mana sinyal nyata, dan mana hanya noise yang berbalut urgensi.

Setiap peta jalan, setelah dirilis sebulan bisa sudah usang. Kerangka yang kamu kuasai bulan lalu, sekarang sudah usang. Benchmark yang pernah kamu optimasi, setelah dilampaui orang lain, cepat tergantikan. Dulu, kita dilatih mengikuti jalur tradisional: satu tumpukan teknologi, satu rangkaian tema dan level; satu rangkaian pengalaman kerja, satu pengalaman dan jabatan; perlahan naik tangga. Tapi AI mengubah kanvas ini. Hari ini, selama prompt digunakan dengan tepat dan penilaian estetika cukup baik, seseorang bisa menyelesaikan pekerjaan yang dulu membutuhkan engineer berpengalaman dua tahun dalam satu sprint.

Kemampuan profesional tetap penting. Tidak ada yang bisa menggantikan pengalaman melihat sistem crash, mengatasi memory leak di tengah malam, atau memutuskan solusi membosankan tapi benar dan akhirnya terbukti benar. Penilaian seperti ini akan berkembang secara kompaun. Tapi yang tidak lagi berkembang secara kompaun adalah familiaritas kamu terhadap «API kerangka kerja populer minggu ini»—yang mungkin berubah lagi dalam enam bulan. Dua tahun kemudian, pemenang sejati adalah mereka yang sudah memilih kemampuan dasar yang tahan lama dan membiarkan noise berlalu.

Dua tahun terakhir, saya membangun produk di bidang ini, menerima beberapa tawaran gaji di atas 25 ribu dolar per tahun, dan saat ini bertanggung jawab di perusahaan yang tidak terlihat. Jika seseorang bertanya, «Apa yang harus saya fokuskan sekarang?», inilah yang akan saya kirimkan padanya.

Ini bukan peta jalan. Bidang Agen AI belum memiliki tujuan yang pasti. Laboratorium besar juga terus beriterasi secara terbuka, mengembalikan masalah ke pengguna jutaan, lalu menulis review dan memperbaiki secara online. Jika tim di balik Claude Code merilis versi yang menyebabkan 47% penurunan performa, dan baru disadari setelah komunitas pengguna menemukannya, maka gagasan «peta jalan yang stabil di bawah sana» hanyalah fiksi. Semua orang masih mencari. Startup punya peluang karena raksasa pun tidak tahu jawaban pasti. Orang yang tidak bisa coding sedang berkolaborasi dengan agen, mengirimkan sesuatu yang bahkan para PhD machine learning anggap tidak mungkin pada hari Selasa, selesai pada hari Jumat.

Hal paling menarik dari momen ini adalah bahwa ia mengubah pemahaman kita tentang «kredensial». Jalur tradisional mengutamakan kredensial: gelar, posisi entry-level, posisi senior, dan jabatan yang diperoleh secara perlahan. Ini masuk akal saat bidang dasar tidak mengalami perubahan besar. Tapi sekarang, tanah di bawah kaki kita bergerak dengan kecepatan yang sama. Seorang pemuda 22 tahun yang mempublikasikan demo agen, dan seorang engineer berpengalaman 35 tahun, tidak lagi hanya berbeda dalam pengalaman 10 tahun menguasai tumpukan teknologi. Mereka berdua menghadapi kanvas kosong yang sama. Yang benar-benar akan berkembang secara kompaun adalah keinginan untuk terus mengirimkan hasil, dan sebagian kecil kemampuan dasar yang tidak usang dalam satu kuartal.

Ini adalah inti dari rekonstruksi artikel ini. Berikutnya, saya akan berikan cara menilai: kemampuan dasar mana yang layak kamu investasikan, dan mana yang bisa kamu lewati. Yang cocok, ambil; yang tidak, biarkan.

Filter yang benar-benar efektif

Kamu tidak mungkin mengikuti setiap rilis mingguan, dan seharusnya tidak perlu. Yang kamu butuhkan bukan aliran informasi, melainkan filter.

Dalam 18 bulan terakhir, ada lima pertanyaan yang tetap relevan. Sebelum memasukkan sesuatu ke dalam tumpukan teknologi, tanyakan lima pertanyaan ini.

Apakah ini masih penting dalam dua tahun?
Jika itu hanya lapisan luar dari model terbaru, CLI parameter, atau versi Devin tertentu, jawabannya hampir selalu tidak. Jika itu adalah primitive dasar seperti protokol, pola memori, metode sandbox, jawabannya lebih mungkin ya. Produk yang hanya berupa lapisan luar cepat usang, primitive dasar bisa bertahan tahunan.

Apakah ada orang yang kamu hormati yang sudah membuat produk nyata berdasarkan ini dan pernah menulis pengalaman secara jujur?
Artikel marketing tidak dihitung, review dan pengalaman nyata ya. Blog berjudul «Kami coba di lingkungan produksi X, dan ini masalahnya» jauh lebih berharga daripada sepuluh pengumuman. Sinyal yang benar-benar berguna selalu berasal dari mereka yang pernah mengorbankan waktu akhir pekan demi ini.

Mengadopsi ini berarti kamu harus menghapus tracing, mekanisme retry, konfigurasi, sistem autentikasi yang ada?
Kalau iya, itu adalah kerangka yang berusaha menjadi platform. Kerangka seperti ini punya risiko 90%. Primitive yang baik harus bisa diintegrasikan ke sistem yang sudah ada, bukan memaksa migrasi.

Apa biaya jika kamu melewatkan ini selama enam bulan?
Bagi sebagian besar rilis, jawabannya tidak ada. Enam bulan kemudian, kamu akan tahu lebih banyak, dan versi yang menang akan lebih jelas. Pertanyaan ini memungkinkan kamu melewati 90% rilis tanpa rasa takut. Tapi banyak yang menolaknya karena merasa tertinggal. Padahal sebenarnya tidak.

Bisakah kamu mengukur apakah ini benar-benar membuat agenmu lebih baik?
Kalau tidak, itu cuma tebakan. Tim tanpa evaluasi berjalan berdasarkan feeling, dan akhirnya mengirimkan masalah regresi ke produksi. Tim dengan evaluasi bisa membiarkan data memberi tahu: apakah GPT-5.5 lebih baik dari Opus 4.7 minggu ini.

Kalau kamu hanya mengambil satu kebiasaan dari artikel ini, itu adalah: setiap kali ada rilis baru, tuliskan apa yang harus kamu lihat dalam enam bulan agar percaya itu penting. Lalu kembali enam bulan kemudian dan cek. Biasanya, jawaban sudah ada, dan perhatianmu akan tertuju pada hal-hal yang benar-benar bisa memberi manfaat secara kompaun.

Sinyal nyata dari pengujian ini jauh lebih sulit dinamai. Ini adalah kemampuan untuk tidak ikut tren. Kerangka yang sedang viral di Hacker News minggu ini akan punya pengikut dalam dua minggu, yang terdengar sangat pintar. Tapi setengah dari mereka sudah tidak aktif lagi dalam enam bulan, dan mereka beralih ke tren berikutnya. Mereka yang tidak ikut bisa menghemat perhatian, dan fokus pada hal-hal yang tetap relevan setelah tren berlalu. Menahan diri, bersikap menunggu, dan berkata «Saya akan tahu dalam enam bulan» adalah keahlian profesional sejati di bidang ini. Semua orang membaca pengumuman, tapi hampir tidak ada yang mahir menahan diri dari reaksi.

Apa yang harus dipelajari

Konsep, pola, bentuk dari sesuatu. Yang benar-benar memberi manfaat adalah hal-hal ini. Mereka bisa melampaui pergantian model, kerangka, dan paradigma. Memahami ini secara mendalam memungkinkan kamu menguasai alat baru dalam satu akhir pekan. Mengabaikan ini berarti terus-menerus belajar mekanisme permukaan.

Rekayasa Konteks

Dalam dua tahun terakhir, perubahan terbesar adalah dari «Prompt Engineering» menjadi «Context Engineering». Perubahan ini nyata, bukan sekadar istilah.

Model tidak lagi hanya menerima instruksi cerdas. Ia menjadi sesuatu yang harus kamu susun konteks yang bisa bekerja di setiap langkahnya. Konteks ini mencakup instruksi sistem, skema alat, dokumen yang diambil, output alat sebelumnya, scratchpad, dan riwayat yang dikompresi. Perilaku agen muncul dari semua yang kamu masukkan ke dalam jendela konteks.

Kamu harus internalisasi: konteks adalah status. Token yang tidak relevan mengurangi kualitas inferensi. Konteks yang membusuk adalah kegagalan nyata. Pada langkah kedelapan dari tugas sepuluh langkah, tujuan awal bisa tertimbun oleh output alat. Tim yang mampu membangun agen yang andal akan secara aktif merangkum, mengompresi, dan memangkas konteks. Mereka mengelola versi deskripsi alat, cache bagian statis, dan menolak cache bagian yang berubah. Mereka memperlakukan jendela konteks seperti engineer berpengalaman memperlakukan memori.

Cara konkretnya: ambil agen dari lingkungan produksi, buka log trace lengkapnya. Lihat konteks di langkah pertama, lalu di langkah ketujuh. Hitung berapa token yang masih berperan. Saat pertama kali melakukan ini, kemungkinan besar akan merasa malu. Tapi kemudian kamu akan memperbaikinya, dan agen yang sama tanpa mengubah model atau prompt akan menjadi lebih andal.

Kalau kamu hanya membaca satu artikel terkait, bacalah Effective Context Engineering for AI Agents dari Anthropic. Lalu baca review mereka tentang sistem riset multi-agen, yang menunjukkan secara angka pentingnya isolasi konteks saat skala sistem membesar.

Desain alat

Alat adalah tempat agen berinteraksi dengan bisnis kamu. Model memilih alat berdasarkan nama dan deskripsi, dan memutuskan retry berdasarkan pesan error. Kesepakatan alat yang sesuai dengan cara LLM mengekspresikan sangat menentukan keberhasilan model.

Lima sampai sepuluh alat yang diberi nama baik jauh lebih baik daripada dua puluh alat yang biasa-biasa saja. Nama alat harus seperti frasa kerja dalam bahasa Inggris alami. Deskripsi harus jelas kapan harus digunakan dan kapan tidak. Pesan error harus memberi feedback yang bisa diambil tindakan oleh model. «Melebihi batas 500 token, silakan ringkas dulu dan coba lagi» jauh lebih baik daripada «Error: 400 Bad Request». Tim riset di satu perusahaan melaporkan bahwa mereka hanya dengan menulis ulang pesan error, mengurangi siklus retry sebesar 40%.

Writing tools for agents dari Anthropic adalah titik awal yang bagus. Setelah membacanya, tambahkan observasi ke alat kamu dan lihat pola panggilan nyata. Peningkatan keandalan agen hampir selalu terjadi di sisi alat. Banyak orang terus mengubah prompt, tapi mengabaikan leverage utama di sini.

Polanya: 2024 dan 2025, diskusi tentang multi-agen akhirnya mengarah ke solusi komprehensif yang sekarang banyak dipakai. Sistem multi-agen yang naif—beberapa agen menulis ke status bersama secara paralel—berisiko gagal karena error yang terus menumpuk. Loop satu agen bisa berkembang jauh lebih jauh dari yang kamu bayangkan. Satu-satunya bentuk multi-agen yang benar-benar bisa digunakan di produksi adalah: satu agen orchestrator yang mengdelegasikan tugas terbatas dan read-only ke subagent yang terisolasi, lalu menggabungkan hasilnya.

Contoh: sistem riset Anthropic, dan subagent Claude Code, bekerja seperti ini. Spring AI dan kerangka kerja produksi lainnya juga mengadopsi pola ini. Subagent memiliki konteks kecil dan fokus, tidak bisa mengubah status bersama. Penulisan dilakukan oleh orchestrator.

Don’t Build Multi-Agents dari Cognition dan How we built our multi-agent research system dari Anthropic tampak berlawanan, tapi sebenarnya hanya berbeda istilah dari hal yang sama. Keduanya layak dibaca.

Gunakan satu agen saja secara default. Baru jika benar-benar menghadapi batasan nyata, pertimbangkan pola orchestrator-subagent: misalnya, tekanan jendela konteks, delay karena panggilan alat berurutan, atau heterogenitas tugas yang memang bisa diuntungkan dari fokus konteks. Jangan membangun ini sebelum benar-benar perlu, karena akan menambah kompleksitas yang tidak perlu.

Evaluasi dan dataset emas

Setiap tim yang mampu mengirim agen yang andal pasti punya evaluasi. Tanpa evaluasi, biasanya tidak bisa mengirim agen yang andal. Ini adalah kebiasaan dengan leverage tertinggi di bidang ini, dan yang paling sering diabaikan.

Praktik terbaik: kumpulkan trace dari lingkungan produksi, tandai kasus gagal, jadikan sebagai dataset regresi. Saat ada kegagalan baru, tambahkan ke dataset. Gunakan LLM sebagai juri untuk bagian subjektif, dan cocokkan secara presisi atau otomatisasi untuk bagian lain. Sebelum melakukan perubahan prompt, model, atau alat, jalankan suite pengujian. Blog engineering Spotify melaporkan bahwa lapisan juri mereka bisa menahan sekitar 25% output agen sebelum dirilis. Tanpa itu, satu dari empat hasil buruk akan sampai ke pengguna.

Inti dari mental model ini: evaluasi adalah seperti pengujian unit, memastikan agen tidak menyimpang dari tugasnya saat semua hal lain berubah. Model akan rilis versi baru, kerangka kerja mengubah secara destruktif, vendor menghentikan endpoint. Evaluasi adalah satu-satunya yang memberi tahu apakah agen masih berfungsi normal. Tanpa evaluasi, kamu menulis sistem yang keabsahannya bergantung pada target yang bergerak.

Framework evaluasi seperti Braintrust, Langfuse evals, LangSmith cukup bagus. Tapi bukan hambatan utama. Hambatan utama adalah memiliki dataset berlabel. Mulailah dari hari pertama, buat dan labeli 50 sampel secara manual. Tidak ada alasan untuk tidak memulai dari situ.

Anggap sistem file sebagai status, dan gunakan siklus Think-Act-Observe

Untuk agen yang melakukan pekerjaan multi langkah nyata, arsitektur yang tahan lama adalah: berpikir, bertindak, mengamati, ulangi. Sistem file atau penyimpanan terstruktur adalah sumber fakta. Setiap aksi dicatat dan bisa diputar ulang. Claude Code, Cursor, Devin, Aider, OpenHands, goose semua mengarah ke sini, bukan tanpa alasan.

Model sendiri tidak memiliki status. Kerangka kerja harus berstatus. Sistem file adalah primitive berstatus yang sudah dipahami semua pengembang. Setelah menerima kerangka ini, disiplin harness akan berkembang secara alami: checkpoint, kemampuan pulih, verifikasi sub-agent, eksekusi sandbox.

Pelajaran lebih dalam: di agen produksi yang layak bayar, harness melakukan lebih banyak pekerjaan daripada model. Model memilih langkah berikutnya, harness memverifikasi, menjalankan di sandbox, menangkap output, memutuskan feedback, kapan berhenti, kapan checkpoint, kapan buat subagent. Ganti model dengan model lain yang setara, harness yang baik tetap bisa mengirim produk. Ganti harness dengan yang lebih buruk, bahkan model terbaik pun bisa menghasilkan agen yang acak lupa apa yang sedang dilakukan.

Kalau kamu membangun sesuatu yang lebih kompleks dari sekadar panggilan alat satu kali, fokus utama harus pada harness. Model hanyalah salah satu komponennya.

Memahami MCP secara konsep

Jangan cuma belajar cara memanggil MCP server. Pelajari modelnya. Ia membangun pemisahan yang jelas antara kemampuan agen, alat, dan sumber daya, serta menyediakan skema otentikasi dan transmisi yang scalable. Setelah memahami ini, semua framework integrasi agen lain akan tampak seperti versi rendah dari MCP, dan kamu bisa menghemat waktu evaluasi satu per satu.

Linux Foundation kini mengelola MCP. Semua penyedia model utama mendukungnya. Anggap saja sebagai «USB-C AI», yang sekarang lebih dekat ke kenyataan daripada sindiran.

Sandboxing adalah primitive dasar

Setiap agen coding produksi berjalan di sandbox. Setiap agen browser pernah mengalami prompt injection tidak langsung. Setiap agen multi-penyewa pernah mengalami bug hak akses. Sandboxing harus dianggap sebagai primitive infrastruktur, bukan fitur yang ditambahkan setelah diminta pelanggan.

Pelajari dasar-dasarnya: isolasi proses, kontrol keluar jaringan, manajemen kunci, batas otentikasi antara agen dan alat. Tim yang menambahkan ini belakangan biasanya kehilangan peluang. Tim yang dari awal mengintegrasikan, akan lebih mudah melewati proses pengadaan perusahaan.

Apa yang harus digunakan untuk membangun

Berikut adalah pilihan spesifik sampai April 2026. Pilihan ini akan berubah, tapi tidak terlalu cepat. Di level ini, pilihlah yang «biasa tapi stabil».

Layer Orkestrasi

LangGraph adalah pilihan default di lingkungan produksi. Sekitar sepertiga perusahaan besar yang menjalankan agen menggunakannya. Pendekatannya sesuai dengan bentuk nyata sistem agen: status berjenis, batas kondisi, workflow yang persisten, dan checkpoint human-in-the-loop. Kekurangannya agak verbose; kelebihannya, saat agen benar-benar masuk ke produksi, kamu memang perlu kontrol ini, dan verbose-nya cocok dengan kebutuhan kontrol tersebut.

Kalau timmu pakai TypeScript, Mastra adalah pilihan utama. Ini adalah solusi dengan model mental paling jelas di ekosistem ini.

Kalau timmu suka Pydantic dan ingin tipe aman sebagai prioritas, Pydantic AI adalah pilihan yang masuk akal untuk greenfield. Versi 1.0 dirilis akhir 2025, dan memang ada momentum.

Kalau pekerjaan provider-native seperti penggunaan komputer, suara, interaksi real-time, bisa pakai Claude Agent SDK atau OpenAI Agents SDK di node LangGraph. Jangan coba jadikan mereka sebagai orchestrator heterogen. Mereka dioptimalkan untuk skenario masing-masing.

Layer protokol

MCP, tidak ada yang lain.

Integrasikan alatmu sebagai MCP server. Konsumsi juga secara eksternal dengan cara yang sama. Sekarang registry MCP sudah melewati titik kritis: dalam banyak kasus, sebelum kamu membangun sendiri, sudah ada server yang siap pakai. Pada 2026, menulis custom plumbing alat secara manual sudah jarang dilakukan.

Layer memori

Saat memilih sistem memori, jangan berdasarkan tren, tapi berdasarkan tingkat otonomi agen.

Mem0 cocok untuk personalisasi chat: preferensi pengguna, riwayat ringan. Zep cocok untuk sistem dialog produksi, terutama yang evolusinya berkelanjutan dan membutuhkan pelacakan entitas. Letta cocok untuk agen yang harus konsisten dalam siklus kerja beberapa hari atau minggu. Kebanyakan tim tidak butuh ini; tapi yang benar-benar membutuhkannya, memang membutuhkannya.

Kesalahan umum: belum masalah memori, sudah pakai framework memori. Mulailah dari isi jendela konteks yang bisa ditampung, lalu tambahkan basis data vektor. Baru jika kamu tahu pasti apa gagal, baru tambahkan sistem memori.

Observabilitas dan evaluasi

Langfuse adalah pilihan open-source default. Bisa di-host sendiri, lisensi MIT, meliputi tracing, manajemen versi prompt, dan evaluasi LLM-as-judge dasar. Kalau kamu pengguna LangChain, integrasi LangSmith lebih erat. Braintrust cocok untuk workflow evaluasi riset, terutama yang membutuhkan perbandingan ketat. OpenLLMetry / Traceloop cocok untuk instrumentasi OpenTelemetry yang vendor-neutral dan multi-bahasa.

Kamu harus punya tracing dan evaluasi. Tracing menjawab: «apa yang dilakukan agen?». Evaluasi menjawab: «apakah agen membaik dari kemarin, atau memburuk?». Tanpa keduanya, tidak boleh rilis. Pasang ini sejak awal, biayanya jauh lebih murah daripada menambah setelah proses berjalan.

Runtime dan sandbox

E2B cocok untuk eksekusi sandbox kode umum. Browserbase dengan Stagehand cocok untuk otomatisasi browser. Anthropic Computer Use cocok untuk skenario yang membutuhkan kontrol desktop tingkat sistem operasi nyata. Modal cocok untuk tugas singkat mendadak.

Jangan pernah jalankan kode tanpa sandbox. Agen yang diretas prompt injection, jika dijalankan langsung di produksi, akan berpotensi menyebabkan kerusakan besar yang sulit dijelaskan.

Model

Mengikuti benchmark capek dan sering tidak membantu. Secara praktis, sampai April 2026:

·Claude Opus 4.7 dan Sonnet 4.6 cocok untuk panggilan alat yang andal, konsistensi multi-langkah, dan pemulihan gagal yang elegan. Untuk sebagian besar beban kerja, Sonnet adalah titik manis antara biaya dan performa.

·GPT-5.4 dan GPT-5.5 cocok untuk kemampuan CLI / terminal reasoning terbaik, atau jika kamu sudah hidup di infrastruktur OpenAI.

·Gemini 2.5 dan 3 cocok untuk tugas dengan konteks panjang dan multimodal.

·Kalau biaya lebih penting dari performa tertinggi, terutama untuk tugas yang jelas batasnya dan sempit, pertimbangkan DeepSeek-V3.2 atau Qwen 3.6.

Anggap model sebagai komponen yang bisa diganti. Jika agenmu hanya bisa berjalan di satu model, itu bukan keunggulan kompetitif, melainkan tanda buruk. Gunakan evaluasi untuk menentukan model mana yang akan dipasang. Evaluasi ulang setiap kuartal, jangan setiap minggu.

Apa yang bisa dilewati

Kamu akan terus didorong untuk belajar dan menggunakan hal-hal berikut ini. Tapi sebenarnya tidak perlu. Mengabaikannya biayanya rendah, dan waktumu akan banyak tersimpan.

AutoGen dan AG2, jangan digunakan di produksi.
Framework Microsoft ini sudah beralih ke komunitas, ritme rilisnya stagnan, dan abstraksinya tidak sesuai kebutuhan tim produksi. Bisa untuk eksplorasi akademik, tapi jangan jadikan produk utama.

CrewAI, jangan digunakan untuk pembangunan produksi baru.
Banyak terlihat karena cocok untuk demo. Tapi engineer yang membangun sistem produksi nyata sudah mulai beralih dari sana. Kamu bisa pakai untuk prototipe, tapi jangan terikat jangka panjang.

Microsoft Semantic Kernel, kecuali kamu sudah sangat terikat di ekosistem Microsoft dan pembeli juga peduli.
Ini bukan arah ekosistem yang sedang berkembang.

DSPy, kecuali kamu fokus mengoptimasi prompt secara besar-besaran.
Memiliki filosofi yang bagus, tapi audiensnya sempit. Bukan kerangka agen umum, dan jangan anggap sebagai kerangka umum.

Menganggap agen penulis kode independen sebagai pilihan arsitektur.
Code-as-action menarik sebagai riset, tapi bukan mode default di produksi. Banyak masalah alat dan keamanan yang akan kamu hadapi, sementara kompetitor mungkin tidak.

Promosi «Autonomous agent».
AutoGPT dan BabyAGI sudah mati secara produk. Industri akhirnya mengakui istilah «agentic engineering»: pengawasan, batasan, evaluasi. Mereka yang masih menjual «agent otonom yang tidak perlu dipantau setelah deploy» di 2026 sebenarnya menjual produk tahun 2023.

Marketplace dan app store agen.
Sejak 2023, sudah ada janji, tapi belum pernah benar-benar mendapatkan traction perusahaan. Perusahaan tidak akan membeli agen prebuilt yang umum. Mereka mau agen vertikal yang terkait hasil tertentu, atau membangun sendiri. Jangan bangun bisnis berdasarkan mimpi app store.

Sebagai pelanggan, berhati-hatilah memilih platform perusahaan yang «build any agent» secara horizontal.
Contohnya Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio. Mungkin berguna nanti, tapi sekarang masih kacau dan lambat rilis, dan biasanya lebih menguntungkan buat mereka untuk membangun sendiri daripada beli. Salesforce Agentforce dan ServiceNow Now Assist adalah pengecualian karena sudah terintegrasi dalam workflow yang kamu pakai.

Jangan mengikuti peringkat SWE-bench dan OSWorld.
Peneliti Berkeley catat tahun 2025 bahwa hampir semua benchmark terbuka bisa dipalsukan, tanpa menyelesaikan tugas dasar. Sekarang, tim lebih percaya pada Terminal-Bench 2.0 dan evaluasi internal mereka sebagai sinyal yang lebih nyata. Rata-rata, mereka skeptis terhadap lonjakan angka benchmark tunggal.

Struktur multi-agen paralel yang naif.
Lima agen yang ngobrol di satu memori bersama terlihat keren di demo, tapi di produksi akan gagal total. Kalau kamu tidak bisa gambarkan diagram jelas tentang orchestrator dan subagent, dan batas baca tulisnya, jangan rilis.

Produk agen baru jangan pakai harga per seat SaaS.
Pasar beralih ke outcome-based dan usage-based. Harga per seat tidak hanya mengurangi margin, tapi juga memberi sinyal bahwa kamu sendiri tidak yakin produk bisa hasilkan hasil.

Framework berikutnya yang kamu lihat di Hacker News minggu ini.
Tunggu enam bulan. Kalau masih penting, kamu tahu. Kalau tidak, kamu sudah menghemat migrasi.

Langkah konkret yang harus diambil

Kalau kamu tidak hanya ingin «mengikuti agen», tapi benar-benar ingin mengadopsi agen, urutan berikut ini efektif. Mungkin membosankan, tapi berguna.

Mulai dari hasil penting yang sudah nyata. Jangan mulai dari moonshot, jangan langsung buat platform agen horizontal. Pilih sesuatu yang memang relevan dan bisa diukur: kurangi tiket customer service, buat draft legal awal, filter inbound leads, buat laporan bulanan. Keberhasilan agen tergantung apakah hasil ini membaik. Ini harus jadi target evaluasi dari hari pertama.

Langkah ini sangat penting karena akan membatasi semua keputusan berikutnya. Dengan hasil spesifik, «pilih kerangka apa» bukan lagi soal filosofi, tapi soal yang tercepat untuk capai hasil itu. «Pilih model apa» bukan lagi soal benchmark, tapi soal model yang terbukti efektif lewat evaluasi. «Perlukah memori, subagent, harness kustom» bukan lagi eksperimen, tapi hanya ditambahkan saat benar-benar diperlukan.

Tim yang melewatkan langkah ini biasanya akan membangun platform horizontal yang tidak diinginkan. Tim yang serius akan membangun agen yang sempit tapi bisa balik modal dalam satu kuartal. Agen yang benar-benar dioperasikan akan mengajarkan mereka lebih banyak daripada belajar dari dua tahun artikel.

Sebelum rilis apa pun, pasang tracing dan evaluasi. Pilih Langfuse atau LangSmith, sambungkan. Jika perlu, buat dataset emas kecil secara manual. 50 sampel sudah cukup. Kamu tidak bisa memperbaiki apa yang tidak bisa diukur. Nanti, menambah sistem ini akan jauh lebih mahal, sekitar 10 kali lipat dari langsung melakukannya sekarang.

Mulai dari satu siklus agen satu. Pilih LangGraph atau Pydantic AI. Model pilih Claude Sonnet 4.6 atau GPT-5. Berikan agen tiga sampai tujuh alat yang dirancang baik. Gunakan file system atau database sebagai status. Uji coba ke pengguna kecil dulu, amati traces-nya.

Anggap agen sebagai produk, bukan proyek. Ia akan gagal dengan cara yang tidak kamu duga, dan kegagalan ini adalah peta jalanmu. Bangun regression set dari trace produksi nyata. Setiap perubahan prompt, penggantian model, modifikasi alat harus diuji evaluasi sebelum dirilis. Banyak tim meremehkan ini, padahal di sinilah reliabilitas dibangun.

Hanya jika sudah merasa layak memperluas, tambahkan kompleksitas. Saat konteks menjadi bottleneck, perkenalkan subagent. Saat jendela konteks tidak cukup, gunakan kerangka memori. Saat API dasar tidak memadai, gunakan computer use atau browser use. Jangan rancang dulu, biarkan pola kegagalan membawanya masuk.

Pilih infrastruktur yang «biasa saja». Alat pakai MCP. Sandboxing pakai E2B atau Browserbase. Status pakai Postgres atau penyimpanan data yang sudah ada. Otentikasi dan observabilitas juga pakai sistem yang sudah ada. Infrastruktur aneh jarang jadi faktor penentu, disiplin adalah kunci utama.

Sejak hari pertama, perhatikan model ekonomi unit. Biaya setiap aksi, tingkat cache hit, biaya retry, distribusi panggilan model. Di tahap PoC, agen tampak murah, tapi jika dari awal tidak dipantau biaya berdasarkan outcome, saat skala 100x biaya akan meledak. Sebuah PoC seharga $0.50 per run bisa jadi $50.000 per bulan saat skala sedang. Tim yang tidak sadar ini akan menghadapi rapat CFO yang tidak mereka sukai.

Evaluasi model setiap kuartal, bukan setiap minggu. Tetapkan kuartal. Di akhir kuartal, jalankan evaluasi terhadap model terbaru. Kalau data menunjukkan perlu ganti, ganti. Dengan cara ini, kamu tetap mendapatkan manfaat dari kemajuan model, tanpa tergesa-gesa setiap rilis.

Cara menilai tren

Berikut beberapa sinyal konkret yang menunjukkan sesuatu mungkin benar-benar sinyal: tim engineering yang dihormati menulis postmortem berangka, bukan cuma klaim adopsi; itu adalah primitive dasar seperti protokol, pola, atau infrastruktur, bukan lapisan luar; bisa berinteroperasi dengan sistem yang sudah berjalan, bukan menggantikan; pitch-nya menjelaskan masalah kegagalan yang dipecahkan, bukan kemampuan baru yang dibuka; sudah ada cukup lama, sampai orang bisa menulis blog tentang apa yang tidak berhasil.

Sinyal yang menunjukkan sesuatu hanya noise: setelah 30 hari rilis, masih cuma demo video, tanpa kasus produksi; benchmark melonjak secara tidak wajar; pitch-nya pakai kata «autonomous», «agent OS», atau «build any agent» tanpa batas; dokumentasi kerangka mengasumsikan kamu akan membuang tracing, autentikasi, dan konfigurasi yang ada; jumlah star naik pesat, tapi commit, rilis, kontributor tidak sejalan; Twitter cepat, tapi GitHub tidak.

Kebiasaan berguna setiap minggu: Jumat luang 30 menit untuk baca bidang ini. Baca tiga hal: blog engineering Anthropic, catatan Simon Willison, Latent Space. Kalau minggu ini ada postmortem, baca satu atau dua lagi. Yang lain bisa dilewatkan. Hal yang benar-benar penting tidak akan terlewatkan.

Apa yang perlu diamati selanjutnya

Dua kuartal ke depan, bukan karena mereka pasti menang, tapi karena pertanyaan «ini sinyal atau tidak» belum terjawab sepenuhnya.

Model paralel forking Replit Agent 4.
Ini salah satu dari sedikit solusi yang mencoba jalankan beberapa agen paralel tanpa terjebak status bersama. Kalau bisa terbukti skala, pola orchestrator-subagent bisa berubah.

Kematangan harga outcome-based.
Sierra dan Harvey sudah membuktikan di bidang sempit bahwa ini berhasil. Tapi apakah bisa diterapkan ke bidang lain, atau hanya untuk vertikal tertentu?

Skill sebagai lapisan pengemasan kemampuan.
Penambahan file AGENTS.md dan direktori skill di GitHub menunjukkan munculnya cara baru mengemas kemampuan agen. Apakah ini akan menjadi standar seperti MCP, atau tetap berbeda? Masih terbuka.

Kualitas Claude Code April 2026 dan reviewnya.
Versi yang menyebabkan 47% penurunan performa dirilis dan ditemukan pengguna, bukan internal. Ini menunjukkan bahwa praktik evaluasi agen produksi masih sangat muda. Kalau ini mendorong industri berinvestasi evaluasi online yang lebih baik, itu langkah positif.

Suara menjadi antarmuka layanan pelanggan default.
Sierra sudah melampaui teks akhir 2025. Kalau tren ini berlanjut, delay, gangguan, dan panggilan alat real-time akan jadi masalah utama, dan banyak arsitektur harus dirombak.

Model open-source yang mampu menutup gap kemampuan agen.
DeepSeek-V3.2 yang mendukung thinking-into-tool-use, Qwen 3.6, dan ekosistem model open-source yang lebih luas patut diperhatikan. Biaya dan performa di tugas sempit berubah. Dominasi model tertutup tidak akan bertahan selamanya.

Setiap hal ini bisa dijadikan pertanyaan: «Enam bulan lagi, apa yang harus saya lihat agar percaya ini penting?». Ini adalah tes. Pantau jawabannya, bukan pengumumannya.

Bertaruh di luar akal sehat

Setiap kerangka yang tidak kamu pakai adalah migrasi yang tidak kamu tanggung. Setiap benchmark yang tidak kamu kejar adalah fokus satu kuartal. Perusahaan yang sedang menang—Sierra, Harvey, Cursor—memilih target sempit, membangun disiplin yang membosankan, dan membiarkan noise berlalu.

Jalur tradisional: pilih tumpukan teknologi, kuasai bertahun-tahun, lalu naik tangga. Saat teknologi stabil sepuluh tahun, ini efektif. Tapi sekarang, teknologi berubah setiap kuartal. Pemenang sejati bukan lagi yang mengoptimasi penguasaan tumpukan, tapi yang mengasah rasa, primitive dasar, dan kecepatan pengiriman. Mereka bangun kecil-kecil, belajar dari hasilnya. Orang lain mengikuti karena mereka sudah membuat sesuatu, dan karya mereka adalah kredensial.

Pikirkan ini serius, karena ini pesan utama artikel ini. Kebanyakan dari kita bekerja berdasarkan model yang mengasumsikan dunia cukup stabil agar kredensial bisa berkembang secara kompaun. Kamu belajar, mendapatkan gelar, naik tangga. Dua tahun di sini, tiga tahun di sana, dan resume jadi kunci membuka pintu. Asumsi utama adalah industri di luar cukup stabil.

Tapi bidang Agen AI tidak punya «lawan» yang stabil. Perusahaan yang ingin kamu bergabung mungkin baru enam bulan berdiri. Kerangka yang mereka pakai baru berumur 18 bulan. Protokol dasar mungkin baru dua tahun. Sebagian besar artikel terkenal di bidang ini dari tiga tahun lalu bahkan penulisnya belum di bidang ini. Tidak ada tangga yang bisa didaki, karena bangunannya terus berubah. Saat tangga gagal, satu-satunya cara adalah membuat sesuatu, mempublikasikannya online, dan biarkan karya berbicara sendiri. Ini jalan yang melawan akal, karena melewati sistem kredensial. Tapi di bidang yang terus bergerak, ini satu-satunya jalan yang benar untuk berkembang secara kompaun.

Ini gambaran dari dalam. Bahkan raksasa pun beriterasi terbuka, merilis masalah regresi, menulis review, dan memperbaiki online. Tim yang paling inovatif tahun ini ada yang 18 bulan lalu belum di bidang ini. Orang yang tidak bisa coding sedang berkolaborasi dengan agen, mengirimkan software nyata. PhD bisa tertinggal oleh builder yang memilih primitive dasar dan mulai cepat. Pintu sudah terbuka. Tapi kebanyakan orang masih mencari formulir aplikasi.

Kemampuan yang benar-benar kamu butuhkan sekarang bukanlah «agent». Tapi disiplin menilai apa yang akan berkembang secara kompaun di bidang yang permukaannya terus berubah ini. Rekayasa konteks akan berkembang secara kompaun. Desain alat akan berkembang. Pola orchestrator-subagent akan berkembang. Disiplin evaluasi akan berkembang. Pemikiran harness akan berkembang. Kerangka API yang baru dirilis hari Selasa tidak akan. Setelah kamu mampu membedakan ini, gelombang rilis baru tidak lagi menjadi tekanan, melainkan noise yang bisa diabaikan.

Kamu tidak perlu belajar semua. Kamu perlu belajar yang akan berkembang secara kompaun, dan melewati yang tidak. Pilih satu outcome. Sebelum rilis, pasang tracing dan evaluasi. Pakai LangGraph atau alat setara. Pakai MCP. Tempatkan runtime di sandbox. Mulai dari agen tunggal. Kalau pola kegagalan menarik perhatian, tingkatkan skala. Saat konteks menjadi bottleneck, perkenalkan subagent. Saat jendela konteks tidak cukup, gunakan kerangka memori. Saat API dasar tidak memadai, gunakan computer use atau browser use. Jangan rancang dulu, biarkan pola kegagalan membawanya masuk.

Pilih infrastruktur yang «biasa saja». Alat pakai MCP. Sandboxing pakai E2B atau Browserbase. Status pakai Postgres atau penyimpanan data yang sudah ada. Otentikasi dan observabilitas pakai sistem yang sudah ada. Infrastruktur aneh jarang jadi faktor penentu, disiplin adalah kunci utama.

Sejak hari pertama, perhatikan model ekonomi unit. Biaya setiap aksi, tingkat cache hit, biaya retry, distribusi panggilan model. Di tahap PoC, agen tampak murah, tapi jika dari awal tidak dipantau biaya berdasarkan outcome, saat skala 100x biaya akan meledak. Sebuah PoC seharga $0.50 per run bisa jadi $50.000 per bulan saat skala sedang. Tim yang tidak sadar ini akan menghadapi rapat CFO yang tidak mereka sukai.

Evaluasi model setiap kuartal, bukan setiap minggu. Tetapkan kuartal. Di akhir kuartal, jalankan evaluasi terhadap model terbaru. Kalau data menunjukkan perlu ganti, ganti. Dengan cara ini, kamu tetap mendapatkan manfaat dari kemajuan model, tanpa tergesa-gesa setiap rilis.

Cara menilai tren

Berikut beberapa sinyal konkret yang menunjukkan sesuatu mungkin benar