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

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

Setiap minggu muncul kerangka kerja baru, model baru, benchmark baru, dan produk “10 kali lipat 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: 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 membangun AI Agent yang andal.

Artikel ini bahkan lebih jauh menunjukkan bahwa AI Agent juga mengubah makna “pengalaman”. Dulu, gelar pendidikan, jabatan, dan lama kerja adalah tiket masuk 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 dilewati di tahun 2026 dalam AI Agent, tetapi juga mengingatkan: di era yang semakin bising ini, kemampuan yang paling langka adalah kemampuan menilai apa yang layak dipelajari dan terus-menerus menghasilkan sesuatu yang benar-benar berguna.

Berikut adalah teks asli:

Setiap hari muncul kerangka kerja baru, benchmark baru, produk “10 kali lipat efisiensi” yang baru. Masalahnya bukan lagi “bagaimana saya mengikuti,” tetapi: mana sinyal asli, mana hanya noise yang berbalut urgensi.

Setiap peta jalan, setelah dirilis sebulan bisa sudah usang. Kerangka yang kamu kuasai kuartal lalu, sekarang sudah menjadi usang. Benchmark yang pernah kamu optimasi, setelah dilibas orang, cepat digantikan yang baru. Dulu, kita dilatih mengikuti jalur tradisional: satu tumpukan teknologi, satu rangkaian tema dan level; satu rangkaian pengalaman kerja, satu lama 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 melihat sistem crash, mengatur memori tengah malam, atau memilih solusi membosankan tapi benar dan akhirnya terbukti benar. Penilaian seperti ini akan berkembang secara kumulatif. Tapi yang tidak lagi berkembang seperti dulu adalah tingkat keakrabanmu dengan “API kerangka kerja populer minggu ini”—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.

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

Hal paling menarik saat ini adalah bahwa ini mengubah pemahaman kita tentang “pengalaman”. Jalur tradisional mengutamakan pengalaman: gelar, posisi awal, posisi tinggi, senior, dan kenaikan pangkat perlahan. Saat bidang ini tidak mengalami perubahan besar di dasar, itu masuk akal. Tapi sekarang, tanah di bawah kaki kita bergerak dengan kecepatan yang sama. Seorang pemuda 22 tahun yang mempublikasikan demo agent, dan engineer berpengalaman 35 tahun, tidak lagi hanya berbeda dalam pengalaman 10 tahun. Mereka berhadapan dengan kanvas kosong yang sama. Yang akan berkembang secara kumulatif adalah keinginan untuk terus mengirim, 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 fokuskan, dan mana yang bisa dilewati. Yang cocok, ambil; yang tidak, lepas.

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 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 berlapis-lapis 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 pemasaran tidak dihitung, review pengalaman ya. Blog berjudul “Kami coba di produksi, ini masalahnya” jauh lebih berharga daripada sepuluh pengumuman. Sinyal yang benar-benar berguna selalu berasal dari mereka yang pernah kehilangan akhir pekan untuk itu.

Mengadopsi itu berarti kamu harus mengorbankan tracing, mekanisme retry, konfigurasi, sistem otentikasi yang ada?
Kalau iya, itu adalah kerangka yang berusaha menjadi platform. Kerangka seperti ini punya tingkat kegagalan sekitar 90%. Primitive yang baik harus bisa menyatu dengan sistemmu, bukan memaksamu migrasi.

Apa biaya melewatkannya enam bulan?
Bagi kebanyakan rilis, jawabannya tidak ada. Enam bulan kemudian, kamu tahu lebih banyak, versi yang menang juga lebih jelas. Pertanyaan ini bisa membuatmu melewati 90% rilis tanpa rasa takut. Tapi banyak yang menolaknya karena merasa tertinggal. Padahal tidak.

Bisakah kamu mengukur apakah itu benar-benar membuat agent-mu lebih baik?
Kalau tidak, itu cuma tebakan. Tim tanpa evaluasi berjalan berdasarkan feeling, akhirnya mengirimkan masalah regresi ke produksi. Tim dengan evaluasi bisa membiarkan data memberi tahu: mana yang lebih baik, GPT-5.5 atau Opus 4.7, dalam beban kerja tertentu 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. Biasanya, jawaban sudah ada, dan perhatianmu akan tertuju pada hal yang benar-benar bisa berkembang secara kumulatif.

Sinyal-sinyal ini didukung oleh kemampuan yang jauh lebih sulit disebutkan: kemampuan untuk tidak ikut tren. Minggu ini, kerangka yang viral di Hacker News akan punya penggemar dalam dua minggu, mereka terdengar sangat pintar. Tapi setengah dari kerangka itu akan tidak dipelihara lagi dalam enam bulan, dan penggemar itu akan beralih ke tren berikutnya. Mereka yang tidak terlibat, menyisihkan perhatian untuk hal yang tetap bertahan dan mampu “menjadi membosankan” setelah tren berlalu. Pengendalian diri, menunggu, dan berkata “enam bulan lagi saya tahu” 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 mampu melampaui pergantian model, kerangka, dan paradigma. Memahami ini secara mendalam, kamu bisa langsung menguasai alat baru dalam satu akhir pekan. Lewati ini, kamu akan terus belajar ulang mekanisme permukaan.

Rekayasa Konteks

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

Model bukan lagi sesuatu yang kamu beri instruksi cerdas. Ia menjadi sesuatu yang harus kamu susun konteks yang bisa bekerja di setiap langkah. Konteks ini mencakup instruksi sistem, skema alat, dokumen yang diambil, output alat sebelumnya, status scratchpad, dan riwayat yang dikompresi. Perilaku agent 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. Pada langkah kedelapan dari tugas sepuluh langkah, tujuan awal bisa tertimbun oleh output alat. Tim yang mampu membangun agent andal akan 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 konkret adalah: ambil agent di lingkungan produksi, buka log trace lengkap. Lihat konteks di langkah pertama, dan 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 agent yang sama akan menjadi lebih andal tanpa mengubah model atau prompt.

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 menunjukkan secara angka pentingnya isolasi konteks saat skala sistem membesar.

Desain Alat

Alat adalah tempat agent berinteraksi dengan bisnismu. Model akan memilih alat berdasarkan nama dan deskripsi, dan memutuskan retry berdasarkan pesan error. Kontrak alat yang sesuai dengan cara LLM mengekspresikan sangat menentukan keberhasilan atau kegagalan model.

Lima sampai sepuluh alat bernama baik lebih baik daripada dua puluh alat biasa. Nama alat harus seperti frasa kerja dalam bahasa Inggris alami. Deskripsi harus jelas kapan harus digunakan dan kapan tidak. Pesan error harus memberi umpan balik yang bisa direspons model. “Over 500 token limit, please summarize first” jauh lebih baik daripada “Error: 400 Bad Request.” Tim riset yang melaporkan mereka cukup mengubah 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 keandalan agent hampir selalu terjadi di sisi alat. Banyak orang terus mengubah prompt, tapi mengabaikan leverage utama di sini.

Mode Orchestrator-Subagent

Perdebatan tentang multi-agent di 2024 dan 2025 akhirnya mengarah ke solusi komprehensif yang saat ini banyak digunakan. Sistem multi-agent yang naif, di mana beberapa agent menulis ke status bersama secara paralel, akan gagal secara katastrofik karena kesalahan akan terus mengakumulasi. Loop satu agent bisa berkembang jauh lebih jauh dari yang kamu bayangkan. Satu-satunya bentuk multi-agent yang bisa bekerja di produksi adalah: satu orchestrator agent 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 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 agent saja secara default. Baru jika benar-benar menemui batas nyata, pertimbangkan mode orchestrator-subagent: misalnya, tekanan jendela konteks, delay karena urutan panggilan alat, atau heterogenitas tugas yang memang bisa diuntungkan dari fokus konteks. Jangan bangun sistem ini sebelum benar-benar diperlukan, karena akan menambah kompleksitas yang tidak perlu.

Evals dan Dataset Emas

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

Praktik efektif adalah: kumpulkan trace produksi, tandai kasus gagal, jadikan sebagai dataset regresi. Saat ada kegagalan baru, tambahkan ke dataset. Gunakan LLM sebagai juri untuk bagian subjektif, dan pemeriksaan otomatis untuk bagian lain. Sebelum mengubah prompt, model, atau alat, jalankan suite pengujian. Blog Spotify Engineering melaporkan bahwa lapisan juri mereka bisa menahan sekitar 25% output agent sebelum dirilis. Tanpa itu, satu dari empat hasil buruk akan sampai ke pengguna.

Gagasan utama adalah: eval adalah seperti pengujian unit, memastikan agent tetap sesuai tugas saat semua hal lain berubah. Model dirilis versi baru, kerangka diubah secara destruktif, vendor menghentikan endpoint. Eval adalah satu-satunya indikator bahwa agent masih berfungsi normal. Tanpa eval, kamu menulis sistem yang keberhasilannya bergantung pada target yang bergerak.

Framework eval seperti Braintrust, Langfuse evals, LangSmith cukup bagus. Tapi bukan hambatan utama. Hambatan utama adalah memiliki dataset berlabel. Mulailah dari hari pertama, sebelum memperluas apa pun. 50 sampel awal bisa dilabel manual dalam satu sore. Tidak ada alasan.

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

Untuk agent 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 adalah: di agent produksi yang layak bayar, pekerjaan harness 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 pun bisa menghasilkan agent yang lupa apa yang sedang dilakukan.

Kalau kamu membangun sesuatu yang lebih kompleks dari sekadar panggilan alat satu kali, fokuslah pada harness. Model hanyalah satu komponen.

Memahami MCP secara konsep

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

Linux Foundation kini mengelola MCP. Hampir semua penyedia model utama mendukungnya. Anggap saja seperti “USB-C-nya AI,” yang sekarang lebih dekat ke kenyataan daripada sindiran.

Sandboxing adalah primitive dasar

Setiap agent coding produksi berjalan di sandbox. Setiap agent browser pernah mengalami prompt injection tidak langsung. Setiap agent multi-tenant 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 agent dan alat. Tim yang menambahkan ini belakangan biasanya kehilangan transaksi. Tim yang menanamkan dari minggu pertama akan lebih mudah melewati proses pengadaan perusahaan.

Apa yang harus digunakan untuk membangun

Berikut adalah pilihan spesifik hingga 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 agent menggunakannya. Pendekatannya sesuai dengan bentuk nyata sistem agent: status berjenis, batas kondisi, workflow yang persisten, dan checkpoint human-in-the-loop. Kekurangannya agak verbose; kelebihannya, saat agent 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 pemikiran paling jelas di ekosistem ini.

Kalau timmu suka Pydantic dan ingin tipe aman sebagai prioritas, Pydantic AI adalah pilihan greenfield yang masuk akal. 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. Integrasi eksternal juga pakai cara yang sama. Saat ini, registry MCP sudah melewati titik kritis: dalam banyak kasus, sebelum kamu bangun sendiri, sudah ada server yang siap pakai. Pada 2026, menulis custom plumbing alat secara manual adalah pemborosan.

Layer Memori

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

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 agent yang harus konsisten dalam siklus kerja beberapa hari atau minggu. Kebanyakan tim tidak butuh ini; tapi yang benar-benar membutuhkannya, memang membutuhkannya.

Kesalahan umum adalah: belum ada masalah memori, sudah pakai framework memori. Mulailah dari konten yang bisa muat di jendela konteks, lalu tambahkan basis data vektor. Baru jika kamu tahu pasti pola kegagalan yang ingin diatasi, 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 sebagai juri LLM dasar. Kalau kamu 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 agent lakukan?” Evals menjawab: “apakah agent membaik dari kemarin, atau memburuk?” Tanpa keduanya, tidak boleh rilis. Pasang ini sejak awal, biayanya jauh lebih rendah daripada menambal setelah jalan.

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 yang tidak di sandbox. Agent yang diretas prompt injection, jika dijalankan langsung di produksi, akan berbahaya dan sulit dikendalikan.

Model

Mengikuti benchmark sangat melelahkan dan sering tidak banyak membantu. Secara praktis, hingga 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 dan sempit, pertimbangkan DeepSeek-V3.2 atau Qwen 3.6.

Anggap model sebagai komponen yang bisa diganti. Jika agentmu hanya bisa bekerja di satu model, itu bukan keunggulan, tapi tanda buruk. Gunakan evals untuk memutuskan model mana yang dipasang. Evaluasi ulang setiap kuartal, jangan setiap minggu.

Apa yang bisa dilewati

Kamu akan terus didorong untuk belajar dan menggunakan hal-hal berikut. Tapi sebenarnya tidak perlu. Biaya melewatkannya sangat kecil, dan banyak waktu bisa dihemat.

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 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.
Ini bukan arah ekosistem yang sedang berkembang.

DSPy, kecuali kamu fokus pada optimisasi prompt secara besar-besaran.
Secara filosofi berharga, tapi audiensnya sempit. Bukan kerangka agent 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 tantangan alat dan keamanan, dan pesaingmu mungkin tidak menghadapinya.

Promosi “agent otonom”
.
AutoGPT dan BabyAGI sudah mati secara produk. Industri akhirnya mengakui “agentic engineering”: pengawasan, batasan, evaluasi. Mereka yang masih jual “tanpa perlu dipantau setelah deploy” adalah menjual produk tahun 2023.

Marketplace dan app store agent
.
Sejak 2023, sudah ada janji, tapi belum ada adopsi nyata di perusahaan. Perusahaan tidak beli agent umum yang sudah jadi. Mereka lebih suka agent vertikal yang terkait hasil tertentu, atau bangun sendiri. Jangan bangun bisnis berdasarkan mimpi app store.

Pilih platform perusahaan “build any agent” secara hati-hati.
Contohnya Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio. Mungkin berguna nanti, tapi sekarang masih kacau dan lambat. Biasanya, pilihan terbaik adalah bangun agent sempit sendiri atau beli agent vertikal. Salesforce Agentforce dan ServiceNow Now Assist adalah pengecualian karena sudah terintegrasi dengan workflow yang kamu pakai.

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

Arsitektur multi-agent paralel yang naif.
Lima agent yang ngobrol di shared memory 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 agent 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 tidak yakin produk bisa hasilkan hasil.

Minggu ini di Hacker News, kerangka berikutnya.
Tunggu enam bulan. Kalau nanti tetap penting, kamu tahu. Kalau tidak, kamu sudah menghemat migrasi.

Langkah konkret yang harus diambil

Kalau kamu tidak hanya ingin “mengikuti agent,” tapi benar-benar ingin mengadopsinya, urutan ini efektif. Mungkin membosankan, tapi berguna.

Mulai dari hasil yang penting. Jangan mulai dari moonshot atau bangun platform agent horizontal. Pilih sesuatu yang sudah relevan dan bisa diukur: kurangi tiket customer service, buat draft legal, filter inbound leads, buat laporan bulanan. Keberhasilan agent tergantung peningkatan hasil ini. Ini target eval sejak hari pertama.

Langkah ini sangat penting karena membatasi semua keputusan berikutnya. Dengan hasil spesifik, “pilih kerangka apa” bukan lagi masalah filosofi, tapi memilih yang tercepat untuk capai hasil itu. “Model apa” bukan lagi debat benchmark, tapi memilih model yang terbukti efektif di evals. “Perlukah memori, subagent, harness khusus” bukan lagi eksperimen, tapi hanya ditambahkan saat pola kegagalan muncul.

Tim yang melewatkan langkah ini biasanya akan membangun platform horizontal yang tidak diinginkan. Tim yang serius akan membangun agent sempit yang bisa balik modal dalam satu kuartal. Agent yang benar-benar di produksi akan mengajarkan mereka lebih banyak daripada membaca dua tahun artikel.

Sebelum rilis apa pun, pasang tracing dan evals. Pilih Langfuse atau LangSmith, sambungkan. Jika perlu, buat dataset emas kecil. 50 sampel sudah cukup. Kamu tidak bisa memperbaiki yang tidak terukur. Menambahkan sistem ini nanti biayanya sekitar 10 kali lipat dari langsung melakukannya sekarang.

Mulai dari satu loop agent. Pilih LangGraph atau Pydantic AI. Model pilih Claude Sonnet 4.6 atau GPT-5. Berikan tiga sampai tujuh alat yang dirancang baik. Gunakan file system atau database sebagai status. Rilis ke pengguna kecil dulu, pantau traces.

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

Hanya jika sudah “berhasil” memperluas skala, tambahkan kompleksitas. Kalau konteks sudah tidak cukup, perkenalkan subagent. Kalau jendela konteks tidak cukup, tambahkan kerangka memori. Kalau API dasar tidak cukup, tambahkan penggunaan komputer atau browser. 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 ada. Infrastruktur unik jarang jadi faktor penentu, disiplin adalah kunci utama.

Sejak hari pertama, fokus pada model ekonomi unit. Biaya setiap aksi, hit rate cache, biaya retry, distribusi panggilan model. Saat PoC, agent terlihat murah, tapi jika tidak pantau biaya dari awal, saat skala 100x, biaya bisa meledak. Sebuah PoC seharga $0.50 per run bisa jadi $50.000 per bulan di skala sedang. Tim yang tidak sadar ini akan menghadapi rapat CFO yang tidak mereka inginkan.

Evaluasi model setiap kuartal, bukan setiap minggu. Tetapkan kuartal. Di akhir kuartal, jalankan eval suite dengan model terbaru. Kalau data menunjukkan perlu ganti, ganti. Dengan cara ini, kamu tetap bisa manfaatkan kemajuan model, tapi hindari kekacauan dari perubahan setiap minggu.

Cara menilai tren

Berikut beberapa sinyal konkret yang menunjukkan sesuatu mungkin benar-benar sinyal: tim engineering terkenal 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, sampai orang bisa menulis blog “apa yang tidak berhasil.”

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 batas; dokumentasi kerangka mengasumsikan kamu akan buang tracing, otentikasi, dan konfigurasi lama; jumlah star naik cepat, tapi commit, rilis, kontributor tidak sejalan; Twitter cepat, GitHub tidak.

Kebiasaan berguna setiap minggu adalah: Jumat luangkan 30 menit 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 dilewatkan. Kamu tidak akan melewatkan hal penting.

Apa yang harus diamati selanjutnya

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

Model paralel forking Replit Agent 4.
Ini salah satu dari sedikit solusi yang mencoba “multi-agent paralel” tanpa terjebak status bersama. Kalau bisa bertahan skala besar, mode orchestrator-subagent bisa berubah.

Kemampuan pricing berbasis hasil.
Sierra dan Harvey sudah membuktikan di bidang sempit bahwa ini efektif. Tapi apakah bisa diterapkan ke bidang lain, atau hanya untuk vertikal tertentu?

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

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

Suara menjadi antarmuka customer default.
Channel suara Sierra sudah melebihi teks akhir 2025. Kalau tren ini berlanjut, delay, gangguan, dan kendala real-time akan jadi masalah utama, dan banyak arsitektur harus diubah.

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

Setiap dari hal ini bisa dijadikan pertanyaan: “Enam bulan lagi, apa yang harus saya lihat agar yakin ini penting?” Ini adalah tes. Pantau jawabannya, bukan pengumumannya.

Dugaan di luar akal sehat

Setiap kerangka yang tidak kamu pakai adalah migrasi yang tidak kamu tanggung di masa depan. Setiap benchmark yang tidak kamu kejar adalah fokus satu kuartal. Perusahaan yang saat ini menang—Sierra, Harvey, Cursor—memilih target sempit, membangun disiplin 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 tiap kuartal. Pemenang sejati bukan lagi menguasai satu tumpukan, tapi menilai rasa, primitive dasar, dan kecepatan pengiriman. Mereka bangun kecil, belajar dari hasilnya. Orang lain mengikuti karena mereka sudah membangun sesuatu. Karya adalah pengalaman.

Renungkan ini serius, karena ini pesan utama artikel ini. Kebanyakan dari kita mengikuti model kerja yang mengasumsikan dunia cukup stabil agar pengalaman bisa berkembang secara kumulatif. Kamu belajar, dapat gelar, naik pangkat. Lama-lama, resume jadi tiket masuk. Asumsi utama adalah industri di luar cukup stabil.

Tapi bidang agent tidak punya “lawan” yang stabil. Perusahaan yang ingin kamu gabung mungkin baru enam bulan berdiri. Framework mereka baru 18 bulan. Protokol dasar mungkin baru dua tahun. Banyak artikel terkenal di bidang ini yang penulisnya tiga tahun lalu belum di bidang ini. Tidak ada tangga yang bisa didaki, karena bangunan ini terus berubah. Saat tangga gagal, satu-satunya cara adalah membuat karya, mempublikasikannya, dan biarkan karya itu memperkenalkan diri. Ini jalan yang tidak konvensional, melewati sistem pengalaman, tapi satu-satunya yang benar-benar bisa berkembang secara kumulatif di bidang yang terus bergerak.

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

Kemampuan yang benar-benar kamu butuhkan sekarang bukan “agents,” tapi disiplin menilai apa yang akan berkembang secara kumulatif di bidang yang permukaannya terus berubah. Rekayasa konteks akan berkembang. Desain alat akan berkembang. Mode orchestrator-subagent akan berkembang. Disiplin eval akan berkembang. Pemikiran harness akan berkembang. Kerangka API yang baru dirilis hari Selasa tidak akan. Setelah kamu bisa 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 kumulatif, dan melewati yang tidak. Pilih satu outcome. Pastikan tracing dan evals terpasang sebelum rilis. Pakai LangGraph atau alat setara. Pakai MCP. Tempatkan runtime di sandbox. Mulai dari satu agent. Kalau pola kegagalan menariknya ke kompleksitas, tambahkan skala. Kalau konteks tidak cukup, tambahkan kerangka memori. Kalau API dasar tidak cukup, tambahkan penggunaan komputer atau browser. Jangan rancang dulu, biarkan pola kegagalan membawanya masuk.

Pilih infrastruktur yang “biasa.” Alat pakai MCP. Sandbox pakai E2B atau Browserbase. Status pakai Postgres atau penyimpanan yang sudah ada. Otentikasi dan observabilitas pakai sistem yang ada. Infrastruktur unik jarang jadi faktor penentu, disiplin adalah kunci.

Sejak hari pertama, fokus pada model ekonomi unit. Biaya aksi, hit rate cache, biaya retry, distribusi panggilan model. Saat PoC, agent tampak murah, tapi jika tidak pantau biaya dari awal, saat skala 100x, biaya bisa meledak. Sebuah PoC seharga $0.50 per run bisa jadi $50.000 per bulan di skala sedang. Tim yang tidak sadar ini akan menghadapi rapat CFO yang tidak mereka inginkan.

Evaluasi model setiap kuartal, bukan setiap minggu. Tetapkan kuartal. Di akhir kuartal, jalankan eval suite dengan model terbaru. Kalau data menunjukkan perlu ganti, ganti. Dengan cara ini, kamu tetap bisa manfaatkan kemajuan model, tapi hindari kekacauan dari perubahan setiap minggu.

Cara menilai tren

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

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 batas; dokumentasi kerangka mengasumsikan kamu akan buang tracing, otentikasi, dan