Panduan Pembelajaran AI 2026: Apa yang Dipelajari, Apa yang Digunakan, Apa yang Dihindari

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

Penulis asli:律动BlockBeats

Sumber asli:

Repost: Mars Finance

Catatan editor: Bidang Agen AI sedang memasuki tahap 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 mengejar kerangka terbaru, melainkan kemampuan dasar yang lebih mendasar: rekayasa konteks, desain alat, sistem evaluasi, mode orchestrator-subagent, pemikiran sandbox dan harness. Kemampuan ini tidak akan cepat usang seiring pergantian model, malah akan menjadi fondasi dalam 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 bereksperimen secara 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 dilewati di tahun 2026, tetapi juga mengingatkan: di era yang semakin bising ini, kemampuan yang paling langka adalah kemampuan untuk menilai apa yang layak dipelajari dan terus-menerus menghasilkan sesuatu yang benar-benar berguna.

Berikut adalah teks aslinya:

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

Setiap peta jalan, setelah dirilis sebulan bisa jadi sudah usang. Kerangka yang baru kamu kuasai kuartal lalu, sekarang sudah menjadi usang. Benchmark yang kamu optimasi dulu, setelah dilampaui orang, cepat digantikan yang baru. 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 benar 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 langsung melihat sistem crash, mengatur memori leak tengah malam, atau memutuskan secara berani memilih solusi membosankan tapi benar, yang akhirnya terbukti benar. Penilaian semacam ini akan berkembang secara kompaun. Tapi yang tidak lagi berkembang secara kompaun adalah tingkat keakrabanmu terhadap API kerangka kerja populer minggu ini. Setelah enam bulan, bisa jadi sudah berubah lagi. Dua tahun kemudian, orang yang benar-benar menang adalah mereka yang sudah memilih kemampuan dasar yang tahan lama dan membiarkan noise di sekitarnya berlalu.

Dua tahun terakhir, saya membangun produk di bidang ini, mendapatkan beberapa tawaran gaji di atas 250.000 USD per tahun, dan sekarang bertanggung jawab atas teknologi di sebuah 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 sedang beriterasi secara terbuka, mengembalikan masalah regresi langsung ke ratusan ribu pengguna, lalu menulis review dan perbaikan online. Jika tim di balik Claude Code bisa merilis versi yang menyebabkan penurunan performa 47% dan baru disadari pengguna setelah komunitas menemukan masalahnya, maka gagasan «peta stabil di bawah sana» adalah fiksi. Semua orang masih mencari-cari. 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, diserahkan pada hari Jumat.

Hal paling menarik dari momen ini adalah bahwa ia mengubah pemahaman kita tentang «kredensial». Jalur tradisional mengutamakan kredensial: gelar, posisi junior, senior, dan level pengalaman yang berkembang perlahan. Ini masuk akal selama 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, perbedaannya bukan lagi hanya pengalaman 10 tahun dengan tumpukan teknologi. Mereka berhadapan dengan 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 rilis yang bisa kamu lewati. Yang cocok, ambil; yang tidak, lepaskan.

Filter yang benar-benar efektif

Kamu tidak mungkin mengikuti semua rilis mingguan, dan seharusnya tidak. 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 kamu, tanyakan lima pertanyaan ini.

Masih penting dua tahun kemudian? Jika itu hanya lapisan luar dari model frontier, CLI parameter, atau versi tertentu dari Devin, jawabannya hampir selalu tidak. Jika itu adalah primitive dasar, seperti protokol, pola memori, metode sandbox, jawabannya lebih cenderung ya. Produk yang hanya berupa lapisan luar biasanya cepat usang, primitive dasar bisa bertahan tahunan.

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

Mengadopsinya berarti kamu harus menghapus tracing, mekanisme retry, konfigurasi, sistem autentikasi yang ada? Jika iya, itu adalah kerangka yang berusaha menjadi platform. Kerangka yang berusaha menjadi platform punya tingkat kegagalan sekitar 90%. Primitive dasar yang baik harus bisa diintegrasikan ke sistem yang sudah ada, bukan memaksa migrasi.

Kalau kamu melewatkannya selama enam bulan, apa harganya? Untuk sebagian besar rilis, jawabannya tidak ada. Enam bulan kemudian, kamu akan tahu lebih banyak, dan versi yang menang akan lebih jelas. Tes ini memungkinkan kamu melewati 90% rilis tanpa rasa khawatir. Tapi ini juga yang paling banyak ditolak orang, karena melewatkan sesuatu terasa seperti tertinggal. Padahal sebenarnya tidak.

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

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 benar-benar penting. Lalu kembali enam bulan kemudian dan cek. Kebanyakan waktu, jawaban sudah ada, dan perhatianmu akan tertuju pada hal-hal yang benar-benar bisa memberi manfaat secara kompaun.

Kemampuan nyata di balik tes ini jauh lebih sulit dinamai. Ini adalah kemampuan untuk «tidak ikut tren». Kerangka yang sedang viral di Hacker News minggu ini, dalam dua minggu akan punya penggemar yang merasa sangat pintar. Tapi setengah dari kerangka itu akan tidak dipelihara lagi dalam enam bulan, dan penggemar itu pun sudah beralih ke tren berikutnya. Mereka yang tidak terlibat, menyisihkan perhatian untuk hal-hal yang tetap bertahan dan terbukti tahan banting 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 langsung.

Apa yang harus dipelajari

Konsep, pola, bentuk dari sesuatu. Yang benar-benar memberi manfaat secara kompaun adalah hal-hal ini. Mereka mampu bertahan dari pergantian model, kerangka, dan paradigma. Memahami secara mendalam, kamu bisa langsung menguasai alat baru dalam satu akhir pekan. Mengabaikannya, kamu akan terus-menerus belajar ulang mekanisme permukaan.

Context Engineering

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

Model tidak lagi sekadar tempat kamu menulis instruksi cerdas. Ia menjadi sesuatu yang harus kamu rakitkan 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 adalah hasil 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 kerusakan nyata dalam produksi. Pada langkah kedelapan dari tugas sepuluh langkah, tujuan awal bisa jadi sudah tertutup oleh output alat. Tim yang mampu mengirim agen yang andal akan aktif merangkum, mengompresi, dan memangkas konteks. Mereka mengelola versi deskripsi alat, cache bagian statis, dan menolak cache bagian yang berubah. Mereka memandang jendela konteks seperti engineer berpengalaman memandang memori.

Salah satu cara konkret adalah: ambil agent dari lingkungan produksi, buka log trace lengkapnya. Lihat konteks di langkah pertama, dan di langkah ketujuh. Hitung berapa token yang masih berfungsi. Saat pertama kali melakukan ini, kemungkinan besar akan merasa malu. Tapi kemudian kamu akan memperbaikinya, dan agent yang sama tanpa mengubah model atau prompt akan menjadi jauh 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-agent, yang menggunakan angka untuk menunjukkan betapa pentingnya isolasi konteks saat skala sistem membesar.

Desain alat

Alat adalah tempat agen berinteraksi dengan bisnismu. Model akan memilih alat berdasarkan nama dan deskripsi, dan memutuskan cara retry berdasarkan pesan error. Kontrak alat yang sesuai dengan cara LLM mengekspresikan diri menentukan keberhasilan atau kegagalan 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, kapan tidak. Pesan error harus memberi umpan balik yang bisa direspons model. «Lebih dari 500 token, silakan ringkas dulu sebelum mencoba» jauh lebih baik daripada «Error: 400 Bad Request». Tim riset di publik 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 alatmu, dan lihat pola panggilan nyata. Peningkatan terbesar dalam keandalan agen biasanya terjadi di sisi alat. Banyak orang terus mengutak-atik prompt, tapi mengabaikan leverage utama di sini.

Mode Orchestrator-Subagent

Perdebatan tentang multi-agent di 2024 dan 2025 akhirnya mengarah ke solusi komprehensif yang sekarang banyak digunakan. Sistem multi-agent yang naif, yaitu beberapa agen menulis ke status bersama secara paralel, akan gagal secara katastrofik karena error akan terus mengakumulasi. Loop satu agen bisa diperluas lebih jauh dari yang kamu bayangkan. Satu-satunya bentuk multi-agent yang benar-benar bisa bekerja di produksi adalah: satu agen orchestrator yang menugaskan tugas terbatas dan hanya baca ke subagent yang terisolasi, lalu menggabungkan hasilnya.

Sistem riset Anthropic bekerja seperti ini. Subagent Claude Code juga demikian. Spring AI dan sebagian besar kerangka kerja produksi saat ini juga menstandarkan mode 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 untuk hal yang sama. Keduanya layak dibaca.

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

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 efektif: kumpulkan trace dari lingkungan produksi, tandai kasus gagal, dan jadikan sebagai regresi. Saat ada kegagalan baru, tambahkan ke dataset. Gunakan LLM sebagai hakim untuk bagian subjektif, dan pemeriksaan otomatis atau pencocokan tepat untuk bagian lain. Sebelum melakukan perubahan prompt, model, atau alat, jalankan rangkaian pengujian. Blog engineering Spotify melaporkan bahwa lapisan hakim mereka bisa menahan sekitar 25% output agen sebelum dirilis. Tanpa itu, satu dari empat hasil buruk akan sampai ke pengguna.

Filosofi utama adalah: evaluasi adalah seperti pengujian unit, memastikan agen tidak menyimpang dari tugasnya saat semua hal lain berubah. Model akan rilis versi baru, kerangka akan melakukan perubahan destruktif, vendor akan menghentikan endpoint tertentu. Evaluasi adalah satu-satunya yang bisa memberi tahu apakah agen masih berfungsi normal. Tanpa evaluasi, kamu sedang membangun sistem yang bergantung pada target yang bergerak.

Kerangka evaluasi seperti Braintrust, Langfuse evals, LangSmith cukup bagus. Tapi bukan hambatan utama. Hambatan utama adalah kamu punya dataset berlabel. Mulailah dari hari pertama, dan lakukan sebelum memperluas apa pun. 50 sampel awal bisa dilabeli manual dalam satu sore. Tidak ada alasan.

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 penyimpanan file atau struktur 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 bersifat stateless. Kerangka kerja harus bersifat stateful. 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.

Lebih dalam lagi, dalam agen produksi yang layak bayar, pekerjaan harness jauh lebih banyak 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 sekalipun akan menghasilkan agen yang acak lupa apa yang sedang dilakukan.

Kalau kamu membangun sesuatu yang lebih kompleks dari sekadar panggilan alat satu kali, tempat yang benar untuk diinvestasikan adalah harness. Model hanyalah salah satu komponennya.

Pahami konsep MCP

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

Linux Foundation saat ini 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. Kamu harus menganggap sandbox sebagai primitive infrastruktur, bukan fitur yang ditambahkan setelah pelanggan minta.

Pelajari dasar-dasarnya: isolasi proses, kontrol keluar jaringan, manajemen kunci, batas autentikasi antara agen dan alat. Tim yang menambahkan ini belakangan, biasanya kehilangan peluang. Tim yang menanamkannya sejak minggu pertama, akan lebih mudah melewati proses pengadaan perusahaan.

Apa yang harus digunakan untuk membangun

Berikut 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. Abstraksinya sesuai dengan bentuk nyata sistem agen: status berjenis, kondisi batas, workflow yang persisten, dan checkpoint human-in-the-loop. Kekurangannya adalah verbose; kelebihannya, saat agen benar-benar masuk ke produksi, kamu memang perlu kontrol ini, dan verbose-nya cocok dengan kebutuhan kontrol tersebut.

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

Kalau timmu suka Pydantic dan ingin menjadikan tipe aman sebagai prioritas, Pydantic AI adalah pilihan greenfield yang masuk akal. Dirilis versi 1.0 akhir 2025, dan memang punya 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. Integrasi eksternal juga pakai cara yang sama. Saat ini, registry MCP sudah melewati titik kritis: dalam banyak kasus, sebelum kamu membangun sendiri, sudah ada server yang siap pakai. Kalau masih menulis sendiri pipeline alat di 2026, itu seperti membayar pajak secara sia-sia.

Layer memori

Pilih sistem memori berdasarkan tingkat otonomi agen, bukan tren.

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 ada masalah memori, sudah pakai kerangka memori. Mulailah dari isi jendela konteks, dan tambahkan basis data vektor. Baru jika kamu tahu pasti apa gagal, baru tambahkan sistem memori.

Observabilitas dan evals

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

Kamu harus punya tracing dan evals. Tracing menjawab: «apa yang agen lakukan?» Evals menjawab: «apakah agen membaik dari kemarin, atau memburuk?» Tanpa keduanya, jangan rilis. Pasang ini sejak hari pertama, biayanya jauh lebih murah daripada memperbaiki setelah rilis.

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 langsung dijalankan di produksi, akan menjadi cerita yang sangat buruk.

Model

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

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

·GPT-5.4 dan GPT-5.5 cocok untuk kemampuan reasoning CLI / terminal 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 dengan batasan yang jelas dan definisi 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 evals untuk memutuskan 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. Padahal, tidak perlu. Mengabaikannya berbiaya rendah, dan menghemat banyak waktu.

AutoGen dan AG2, jangan digunakan di produksi. Kerangka 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. Engineer yang membangun sistem produksi nyata sudah beralih dari sana. Kamu bisa pakai untuk prototipe, tapi jangan terikat jangka panjang.

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

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

Anggap agen penulis kode independen sebagai pilihan arsitektur. Code-as-action adalah arah riset menarik, tapi belum menjadi mode default di produksi. Kamu akan menghadapi banyak masalah alat dan keamanan, dan pesaingmu mungkin tidak menghadapinya.

Promosi «autonomous agent» yang berlebihan. AutoGPT dan BabyAGI sudah mati secara produk. Industri akhirnya mengakui istilah jujur: «agentic engineering»: pengawasan, batasan, evaluasi. Mereka yang masih menjual «tanpa perlu pengelolaan setelah deployment» di 2026, sebenarnya menjual sesuatu dari 2023.

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

Sebagai pelanggan, berhati-hatilah memilih platform perusahaan yang «build any agent» secara horizontal. Misalnya Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio. Mereka mungkin berguna nanti, tapi saat ini masih kacau, rilis lambat, dan perhitungan buy-vs-build biasanya condong ke: bangun agen sempit sendiri, atau beli agen vertikal. Salesforce Agentforce dan ServiceNow Now Assist adalah pengecualian, karena sudah terintegrasi dengan workflow yang kamu gunakan.

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

Arsitektur multi-agen paralel yang naif. Lima agen berbagi memori dalam demo terlihat keren, tapi di produksi akan gagal total. Kalau kamu tidak bisa menggambar diagram jelas tentang orchestrator dan subagent, dan menandai 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 ke pembeli bahwa kamu sendiri tidak yakin produk bisa hasilkan hasil.

Minggu ini, kerangka berikutnya yang kamu lihat di Hacker News. Tunggu enam bulan. Kalau nanti masih penting, kamu tahu. Kalau tidak, kamu menghemat satu migrasi.

Langkah konkret yang harus diambil

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

Pilih hasil yang sudah penting. Jangan mulai dari moonshot, jangan langsung buat proyek «platform agen» yang horizontal. Pilih sesuatu yang memang relevan dan bisa diukur: kurangi tiket customer service, buat draft legal review pertama, filter inbound leads, buat laporan bulanan. Keberhasilan agen tergantung apakah hasil ini membaik. Dari hari pertama, ini adalah target evaluasimu.

Langkah ini paling penting karena akan membatasi semua keputusan berikutnya. Dengan hasil spesifik, «kerangka apa yang dipakai» bukan lagi soal filosofi, tapi soal yang paling cepat menghasilkan hasil itu. «Model apa yang dipakai» juga bukan lagi soal benchmark, tapi soal model yang terbukti efektif di evaluasi untuk tugas ini. «Perlukah memori, subagent, harness kustom» juga bukan lagi eksperimen, tapi hanya ditambahkan saat pola kegagalan tertentu muncul.

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

Sebelum rilis apa pun, pasang tracing dan evals. Pilih Langfuse atau LangSmith, dan sambungkan. Jika perlu, buat dataset emas kecil secara manual. 50 sampel sudah cukup untuk mulai. Kamu tidak bisa memperbaiki apa yang tidak bisa diukur. Nanti, menambahkan sistem ini akan jauh lebih murah daripada langsung.

Mulai dari satu loop agen. 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. Rilis ke pengguna kecil dulu, amati traces.

Anggap agen sebagai produk, bukan proyek. Ia akan gagal dengan cara yang tidak terduga, 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 investasi di sini, padahal di sinilah keandalan dibangun.

Hanya jika kamu sudah merasa layak memperluas cakupan, tambahkan kompleksitas. Kalau konteks menjadi bottleneck, baru perkenalkan subagent. Kalau jendela konteks tidak cukup, baru pakai kerangka memori. Kalau API dasar tidak tersedia, baru pakai 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. Autentikasi dan observabilitas juga sebisa mungkin pakai sistem yang ada. Infrastruktur aneh jarang jadi faktor penentu, disiplin adalah kunci utama.

Sejak hari pertama, fokus pada model ekonomi unit. Biaya setiap aksi, tingkat cache hit, biaya retry, distribusi panggilan model. Saat PoC, agen tampak murah, tapi jika dari awal tidak dipantau biaya berdasarkan outcome, saat skala 100x biayanya bisa meledak. Sebuah PoC seharga 0,50 USD per kali, saat skala sedang bisa jadi 50.000 USD per bulan. Tim yang tidak melihat ini akan menghadapi rapat CFO yang tidak mereka inginkan.

Evaluasi model setiap kuartal, bukan setiap minggu. Tetapkan kuartal. Di akhir kuartal, jalankan evaluasi dengan model terbaru. Kalau data menunjukkan perlu diganti, ganti. Dengan cara ini, kamu bisa menikmati manfaat dari kemajuan model, dan menghindari kekacauan dari rilis yang terlalu sering.

Cara menilai tren

Berikut beberapa sinyal konkret yang menunjukkan sesuatu mungkin benar-benar sinyal: tim yang dihormati menulis postmortem berangka, bukan cuma klaim adopsi; itu adalah primitive dasar seperti protokol, pola, atau infrastruktur, bukan lapisan luar atau bundling; 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, sehingga orang bisa menulis blog tentang apa yang tidak berhasil.

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

Kebiasaan mingguan yang berguna: Jumat luangkan 30 menit untuk membaca 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 dilewati. Kamu tidak akan ketinggalan hal yang benar-benar penting.

Apa yang harus diamati selanjutnya

Dua kuartal ke depan, yang patut diperhatikan bukan karena pasti akan menang, tapi karena pertanyaan «apakah ini sinyal» belum terjawab sepenuhnya.

Model paralel Replit Agent 4. Ini salah satu dari sedikit percobaan serius «multi-agent paralel» yang tidak terjebak oleh status bersama. Kalau bisa bertahan saat skala, mode orchestrator-subagent mungkin akan berubah.

Kemapanan harga berbasis outcome. Pendapatan Sierra dan Harvey sudah membuktikan di bidang sempit bahwa ini bisa. Tapi apakah bisa diterapkan di bidang lain, atau hanya cocok untuk skenario vertikal?

Skill sebagai lapisan pembungkus kemampuan. Banyaknya file AGENTS.md dan direktori skill di GitHub menunjukkan munculnya cara baru membungkus kemampuan agen. Apakah ini akan menjadi standar seperti MCP, atau tetap berbeda, itu masih terbuka.

Kualitas rollback Claude Code April 2026 dan reviewnya. Versi yang menyebabkan penurunan performa 47%, ditemukan pengguna dan tim internal. Ini menunjukkan bahwa bahkan di perusahaan terdepan, praktik evaluasi agen produksi masih sangat kurang matang. Kalau kejadian ini mendorong industri berinvestasi dalam evaluasi online yang lebih baik, maka koreksi ini sehat.

Suara menjadi antarmuka pelanggan default. Channel suara Sierra sudah melampaui teks akhir 2025. Kalau tren ini berlanjut di bidang vertikal lain, latensi, gangguan, dan desain panggilan alat real-time akan menjadi masalah utama, dan banyak arsitektur harus dirombak.

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

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

Keberanian melawan arus

Setiap kerangka yang tidak kamu pakai adalah migrasi yang tidak kamu tanggung di masa depan. Setiap benchmark yang tidak kamu kejar adalah fokus selama 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 tumpukan teknologi stabil selama sepuluh tahun, ini efektif. Tapi sekarang, tumpukan teknologi berubah setiap kuartal. Pemenang sejati bukan lagi yang mengoptimalkan penguasaan teknologi, melainkan yang mengasah selera, primitive dasar, dan kecepatan pengiriman. Mereka membangun kecil secara terbuka, belajar dari hasilnya. Orang lain mengikuti karena mereka sudah membuat sesuatu, dan itu menjadi kredensial mereka.

Renungkan ini dengan serius, karena ini adalah pesan utama dari seluruh artikel. Sebagian besar model kerja kita mengasumsikan dunia cukup stabil agar kredensial bisa berkembang secara kompaun. Kamu belajar, mendapatkan gelar, naik tangga. Di sini, tinggal dua tahun, di sana tiga tahun, dan resume perlahan membuka pintu. Asumsi utama adalah industri di seberang cukup stabil.

Tapi bidang agen AI saat ini tidak punya «seberang» 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. Setengah dari artikel yang paling sering dikutip di bidang ini penulisnya tiga tahun lalu bahkan belum di bidang ini. Tidak ada tangga yang bisa didaki, karena bangunan ini terus berubah. Saat tangga gagal, satu-satunya cara adalah: buat sesuatu, unggah ke internet, biarkan karya berbicara. Ini jalan yang tidak konvensional, karena melewati sistem kredensial. Tapi di bidang yang terus bergerak, ini adalah satu-satunya jalan yang benar-benar bisa memberi manfaat secara kompaun.

Ini adalah gambaran dari dalam tentang zaman ini. Bahkan raksasa pun beriterasi terbuka, merilis masalah regresi, menulis review, dan memperbaiki online. Tahun ini, tim yang paling aktif mengirimkan produk, ada yang bahkan 18 bulan lalu belum di bidang ini. Orang yang tidak bisa coding sedang berkolaborasi dengan agen, mengirimkan software nyata. PhD mungkin akan tertinggal oleh mereka yang memilih primitive dasar yang tepat dan mulai bergerak cepat. Pintu sudah terbuka. Tapi kebanyakan orang masih mencari formulir aplikasi.

Kemampuan yang benar-benar perlu kamu asah sekarang bukanlah «agent». Tapi disiplin untuk menilai apa yang akan memberi manfaat secara kompaun di bidang yang permukaannya terus berubah ini. Context engineering akan berkembang secara kompaun. Desain alat akan berkembang secara kompaun. Mode orchestrator-subagent akan berkembang secara kompaun. Disiplin evaluasi akan berkembang secara kompaun. Pemikiran harness akan berkembang secara kompaun. Kerangka API yang baru dirilis hari Selasa tidak akan. Setelah kamu mampu membedakan semuanya, gelombang rilis baru setiap minggu tidak lagi menjadi tekanan, melainkan noise yang bisa kamu abaikan.

Kamu tidak perlu belajar semua. Kamu perlu belajar yang akan berkembang secara kompaun, dan melewati yang tidak. Pilih satu outcome. Pasang tracing dan evals sebelum rilis. Gunakan LangGraph, atau alat setara di timmu. Gunakan MCP. Tempatkan runtime di sandbox. Mulai dari satu agen. Baru jika pola kegagalan menarik, perluas cakupan. Evaluasi model setiap kuartal. Jumat baca tiga hal.

Ini adalah playbook-nya. Sisanya, soal selera, kecepatan pengiriman, dan kesabaran untuk tidak mengikuti hal yang tidak penting.

Bangun sesuatu. Sebarkan ke internet. Era ini menghargai orang yang membuat, bukan cuma yang cuma bisa mendeskripsikan. Sekarang adalah waktu terbaik untuk menjadi orang yang benar-benar membuat.