AI bukanlah sihir, tetapi juga tidak sesederhana “buat program AI, otomatis semua selesai, tunggu hasilnya”. Kebanyakan orang sebenarnya tidak benar-benar memahami apa itu AI.
Dan mereka yang benar-benar mengerti (kurang dari 5%) mencoba membangun sendiri, hasilnya sering gagal. Agen cerdas akan mengalami “ilusi”, lupa langkah apa yang sudah dilakukan di tengah tugas, atau salah memanggil alat saat tidak seharusnya. Saat demo berjalan sempurna, begitu masuk ke lingkungan produksi langsung crash.
Saya sudah mengdeploy program AI selama lebih dari satu tahun. Karir perangkat lunak saya dimulai di Meta, tetapi setengah tahun lalu saya keluar dan mendirikan perusahaan yang khusus mengdeploy agen AI yang siap pakai untuk perusahaan. Sekarang pendapatan tahunan kami sudah mencapai 3 juta dolar AS dan terus bertambah. Ini bukan karena kami lebih pintar dari yang lain, tetapi karena kami terus mencoba-coba, gagal berkali-kali, dan akhirnya menemukan rumus keberhasilan.
Berikut adalah semua yang saya pelajari selama membangun agen cerdas yang benar-benar bisa digunakan. Apapun tingkat keahlianmu—pemula, ahli, atau di antara keduanya—pengalaman ini seharusnya relevan.
Pelajaran pertama: Konteks adalah segalanya
Ini mungkin terdengar sangat jelas, mungkin juga sudah sering kamu dengar. Tapi karena sangat penting, maka perlu ditekankan berulang kali. Banyak orang mengira membangun agen cerdas hanya menghubungkan berbagai alat: pilih model, buka akses database, lalu lepas tangan. Pendekatan ini akan langsung gagal, karena beberapa alasan:
Agen tidak tahu apa yang penting. Ia tidak tahu apa yang terjadi lima langkah sebelumnya, hanya melihat langkah saat ini, lalu menebak apa yang harus dilakukan selanjutnya (sering salah tebak), dan akhirnya mengandalkan keberuntungan.
Konteks, seringkali, adalah perbedaan mendasar antara agen bernilai jutaan dan agen yang tidak berharga sama sekali. Kamu perlu fokus dan mengoptimalkan aspek-aspek berikut:
Apa yang diingat agen: tidak hanya tugas saat ini, tetapi juga seluruh riwayat yang menyebabkan kondisi saat ini. Misalnya saat memproses invoice abnormal, agen perlu tahu: bagaimana abnormalitas itu dipicu, siapa yang mengajukan invoice asli, kebijakan apa yang berlaku, bagaimana penanganan masalah terakhir dengan vendor tersebut. Tanpa riwayat ini, agen hanya menebak-nebak, yang bahkan lebih buruk dari tidak punya agen sama sekali. Karena jika manusia yang menangani, masalah itu mungkin sudah selesai sejak lama. Ini juga menjelaskan mengapa ada yang mengeluh “AI benar-benar sulit digunakan”.
Bagaimana informasi mengalir: saat kamu punya beberapa agen, atau satu agen yang menangani proses multi-langkah, informasi harus ditransfer secara akurat di setiap tahap, tidak boleh hilang, rusak, atau disalahartikan. Agen yang bertugas mengklasifikasi permintaan harus mengirimkan konteks yang bersih dan terstruktur ke agen yang menyelesaikan masalah. Jika transfer tidak rapi, hasilnya akan kacau. Ini berarti setiap bagian harus memiliki input dan output yang terstruktur dan dapat diverifikasi. Contohnya adalah fungsi /compact di Claude Code, yang bisa mentransfer konteks antar sesi LLM berbeda.
Pemahaman agen tentang domain bisnis: agen yang memeriksa kontrak hukum harus tahu bagian mana yang penting, risiko apa yang diperkirakan, dan kebijakan perusahaan yang berlaku. Kamu tidak bisa hanya memberi dokumen dan berharap agen bisa memahami poin penting sendiri, itu tanggung jawabmu. Tanggung jawabmu juga termasuk menyediakan sumber daya secara terstruktur agar agen memiliki pengetahuan domain yang cukup.
Kinerja buruk dalam pengelolaan konteks terlihat dari: agen mengulang panggilan alat yang sama karena lupa sudah mendapatkan jawaban; atau memanggil alat yang salah karena menerima informasi yang salah; atau membuat keputusan yang bertentangan dengan langkah sebelumnya; bahkan setiap kali menganggap tugas sebagai hal baru, mengabaikan pola yang jelas dari tugas serupa sebelumnya.
Pengelolaan konteks yang baik membuat agen seperti seorang pakar bisnis berpengalaman: mampu menghubungkan berbagai informasi tanpa perlu kamu jelaskan secara eksplisit hubungan antar data tersebut.
Konteks adalah kunci untuk membedakan agen yang hanya bisa demo dan agen yang benar-benar berjalan di lingkungan produksi dan menghasilkan output.
Pelajaran kedua: Agen AI adalah pengganda hasil
Pandangan yang salah: “Dengan adanya ini, kita tidak perlu lagi merekrut orang.”
Pandangan yang benar: “Dengan ini, tiga orang bisa melakukan pekerjaan yang dulu dilakukan oleh lima belas orang.”
Agen pasti akan menggantikan sebagian pekerjaan manusia, mengakui hal ini hanyalah kebohongan diri. Tapi sisi positifnya adalah: agen tidak akan menggantikan penilaian manusia, melainkan menghilangkan berbagai gesekan yang muncul dari penilaian manusia, seperti mencari data, mengumpulkan informasi, cross-check, merapikan format, mendistribusikan tugas, mengingatkan tindak lanjut, dan lain-lain.
Contohnya: tim keuangan tetap perlu membuat keputusan terkait abnormalitas, tetapi dengan agen, mereka tidak perlu lagi menghabiskan 70% waktu minggu tutup buku untuk mencari dokumen yang hilang, melainkan bisa memanfaatkan waktu itu untuk menyelesaikan masalah sebenarnya. Agen menyelesaikan semua pekerjaan dasar, manusia hanya melakukan persetujuan akhir. Berdasarkan pengalaman saya melayani klien, kenyataannya adalah: perusahaan tidak akan melakukan PHK karena ini. Pekerjaan karyawan akan bertransformasi dari operasi manual yang membosankan ke tugas yang lebih bernilai, setidaknya untuk saat ini. Tentu saja, dalam jangka panjang, seiring perkembangan AI, situasi ini bisa berubah.
Perusahaan yang benar-benar mendapatkan manfaat dari agen adalah yang tidak hanya ingin mengeluarkan manusia dari proses, tetapi yang menyadari bahwa sebagian besar waktu karyawan dihabiskan untuk “pekerjaan pendukung” dan bukan bagian yang benar-benar menciptakan nilai.
Dengan mendesain agen sesuai pola ini, kamu tidak perlu lagi berdebat soal “akurasi”: biarkan agen melakukan apa yang ia kuasai, manusia fokus pada bidangnya.
Ini juga berarti kamu bisa lebih cepat deploy dan operasikan. Tidak perlu agen menangani semua situasi ekstrem, cukup tangani yang umum dan serahkan yang kompleks dan abnormal ke manusia—dengan konteks yang cukup agar manusia bisa cepat menyelesaikan. Setidaknya, untuk tahap ini, begitulah seharusnya.
Pelajaran ketiga: Manajemen memori dan status
Bagaimana agen menyimpan informasi dalam satu tugas dan antar tugas menentukan apakah ia bisa beroperasi secara skala besar.
Ada tiga pola umum:
Agen independen: menangani seluruh alur kerja dari awal sampai akhir. Ini paling mudah dibangun karena semua konteks ada di satu tempat. Tapi seiring panjangnya proses, manajemen status menjadi tantangan: agen harus mengingat keputusan di langkah ketiga, saat mencapai langkah kesepuluh harus menggunakannya. Jika jendela konteks penuh, atau struktur memorinya tidak tepat, pengambilan keputusan di kemudian hari akan kekurangan informasi awal, menyebabkan kesalahan.
Agen paralel: memproses bagian berbeda dari masalah secara bersamaan. Lebih cepat, tapi menimbulkan masalah koordinasi: bagaimana menggabungkan hasil? Jika dua agen menghasilkan kesimpulan yang bertentangan, apa yang harus dilakukan? Harus ada protokol yang jelas untuk mengintegrasikan informasi dan menyelesaikan konflik. Biasanya perlu ada “wasit” (manusia atau LLM lain) untuk mengatasi konflik atau kondisi balapan.
Agen kolaboratif: menyerahkan pekerjaan secara berurutan. Agen A mengklasifikasi, lalu mengirim ke B untuk riset, kemudian ke C untuk eksekusi solusi. Pola ini cocok untuk alur kerja yang memiliki tahapan jelas, tapi transfer antar agen paling rawan masalah. Apa yang dipelajari agen A harus dikirim ke agen B dalam format yang bisa langsung digunakan.
Kesalahan umum adalah menganggap pola ini sebagai “solusi implementasi”. Padahal, ini adalah keputusan arsitektur yang langsung menentukan batas kemampuan agenmu.
Misalnya kamu ingin membangun agen untuk persetujuan kontrak penjualan, harus diputuskan: apakah satu agen bertanggung jawab penuh? Atau buat agen routing yang membagi tugas ke agen peninjauan harga, peninjauan hukum, persetujuan manajemen, dan lain-lain? Hanya dengan memahami proses bisnis nyata di baliknya, kamu bisa mengajarkan proses ini ke agenmu.
Bagaimana memilih? Tergantung kompleksitas tiap tahap, berapa banyak konteks yang perlu dipindahkan antar tahap, dan apakah setiap tahap harus kolaborasi real-time atau berurutan.
Kalau arsitekturnya salah, kamu bisa menghabiskan berbulan-bulan untuk debugging masalah yang sebenarnya bukan bug. Itu adalah kesalahan desain, masalah yang ingin kamu selesaikan, dan ketidaksesuaian arsitektur solusi.
Pelajaran keempat: Intervensi aktif terhadap abnormalitas, bukan laporan pasca kejadian
Saat membangun sistem AI, reaksi pertama banyak orang adalah: buat dashboard, tampilkan informasinya, biar semua tahu apa yang terjadi. Tolong, jangan lagi buat dashboard.
Dashboard tidak berguna.
Tim keuangan sudah tahu ada dokumen hilang, tim penjualan juga tahu ada kontrak yang terjebak di bagian hukum.
Agen harus langsung mencegah masalah saat terjadi, dan mengalihkan ke orang yang tepat untuk menyelesaikan, sekaligus menyediakan semua informasi yang dibutuhkan, lalu langsung eksekusi.
Invoice datang tapi dokumen tidak lengkap? Jangan cuma catat di laporan. Segera tandai, cari tahu siapa yang harus melengkapi dokumen, dan kirimkan masalah lengkap beserta konteksnya (vendor, jumlah, kebijakan, apa yang kurang). Sekaligus hentikan transaksi masuk sampai masalah terselesaikan. Langkah ini sangat penting, kalau tidak, masalah akan “bocor” ke seluruh organisasi, dan kamu tidak sempat memperbaikinya.
Persetujuan kontrak lebih dari 24 jam belum ada kejelasan? Jangan tunggu rapat mingguan. Otomatis naikkan level, lampirkan detail transaksi, agar yang menyetujui bisa cepat memutuskan tanpa harus cek sistem di mana-mana. Harus ada rasa urgensi.
Vendor tidak memenuhi milestone tepat waktu? Jangan tunggu orang lain yang menyadari. Otomatis aktifkan rencana darurat, dan mulai proses penanganan sebelum masalah membesar.
Tugas agen AI-mu adalah: membuat masalah tidak bisa diabaikan, dan menyelesaikannya dengan sangat mudah.
Langsung ungkap masalah, bukan hanya lewat dashboard.
Ini berlawanan dengan cara kebanyakan perusahaan menggunakan AI: mereka pakai AI untuk “melihat” masalah, sementara kamu harus pakai AI untuk “memaksa” menyelesaikan masalah, dan harus cepat. Setelah tingkat keberhasilan penyelesaian masalah mendekati 100%, baru pertimbangkan buat dashboard.
Pelajaran kelima: Ekonomi agen AI vs SaaS umum
Perusahaan terus membeli SaaS yang tidak digunakan karena alasan tertentu.
SaaS mudah dibeli: ada demo, ada penawaran, ada checklist kebutuhan yang bisa dicentang. Kalau disetujui, dianggap proses berjalan (walaupun sering tidak begitu).
Pembelian SaaS AI paling buruk adalah: seringkali hanya dipajang begitu saja. Tidak terintegrasi dengan alur kerja nyata, jadi cuma jadi sistem lain yang harus login. Kamu dipaksa migrasi data, sebulan kemudian cuma jadi vendor lain yang harus dikelola. Setelah 12 bulan, diabaikan, tapi kamu tidak bisa lepas karena biaya switching terlalu tinggi, jadilah “hutang teknologi”.
Sedangkan AI yang dibangun sendiri dari sistem yang ada akan menghindari masalah ini.
Berjalan di dalam alat yang sudah kamu pakai, tidak menciptakan platform kerja baru, malah mempercepat pekerjaan yang ada. Agen menyelesaikan tugas, manusia hanya melihat hasilnya.
Biaya sebenarnya bukan “biaya pengembangan vs biaya lisensi”, tetapi lebih ke logika sederhana:
SaaS menimbulkan “hutang teknologi”: setiap beli alat baru, bertambah satu integrasi yang harus dipelihara, satu sistem yang akan usang, satu vendor yang mungkin diakuisisi, diubah, atau ditutup.
Membangun agen sendiri menimbulkan “kemampuan”: setiap perbaikan membuat sistem lebih pintar, setiap alur kerja baru memperluas kemungkinan. Investasi ini adalah pertumbuhan majemuk, bukan depresiasi seiring waktu.
Itulah sebabnya selama setahun terakhir saya selalu bilang: SaaS AI umum tidak punya masa depan. Data industri juga membenarkan: sebagian besar perusahaan yang beli SaaS AI berhenti pakai dalam 6 bulan dan tidak melihat peningkatan produktivitas. Yang benar-benar mendapatkan manfaat dari AI adalah perusahaan yang punya agen kustom, baik yang dikembangkan sendiri maupun dari pihak ketiga.
Inilah mengapa perusahaan yang menguasai agen sejak awal akan memiliki keunggulan struktural jangka panjang: mereka membangun infrastruktur yang semakin kuat. Yang lain cuma menyewa alat yang suatu saat harus diganti. Di era perubahan cepat ini, setiap minggu yang terbuang adalah kerugian besar bagi peta jalan produk dan bisnis secara keseluruhan.
Pelajaran keenam: Deploy harus cepat
Kalau rencana proyek AI-mu butuh setahun baru bisa jalan, itu sudah kalah.
Perencanaan tidak bisa mengikuti perubahan. Alur kerja yang dirancang mungkin tidak sesuai kenyataan, dan edge case yang tidak terduga seringkali paling penting. Setelah 12 bulan, dunia AI bisa berubah total, dan apa yang kamu buat mungkin sudah usang.
Maksimal 3 bulan, harus sudah masuk ke lingkungan produksi.
Di era informasi yang meledak ini, kemampuan sejati adalah: tahu cara memanfaatkan informasi secara efektif, dan berkolaborasi dengannya, bukan melawannya. Harus benar-benar mengerjakan: mengelola tugas nyata, membuat keputusan nyata, dan meninggalkan catatan yang bisa dilacak.
Masalah paling umum yang saya lihat adalah: tim pengembang internal sering memperkirakan proyek AI yang seharusnya selesai 3 bulan menjadi 6–12 bulan. Atau lebih buruk—mengatakan 3 bulan, tapi setelah mulai kerja selalu tertunda karena berbagai “alasan tak terduga”. Itu bukan sepenuhnya salah mereka, dunia AI memang kompleks.
Jadi, kamu perlu engineer yang benar-benar paham AI: mereka mengerti bagaimana AI bisa beroperasi secara skala besar, pernah melihat masalah nyata, dan tahu batas kemampuan serta keterbatasan AI. Saat ini terlalu banyak pengembang “setengah matang” yang mengira AI bisa melakukan segalanya—ini jauh dari kenyataan. Kalau kamu ingin masuk ke bidang AI aplikasi perusahaan, kamu harus menguasai batas kemampuan AI secara solid.
Ringkasan
Membangun agen yang bisa digunakan, kuncinya ada di poin-poin ini:
Konteks adalah segalanya: agen tanpa konteks yang baik hanyalah generator angka acak yang mahal. Pastikan aliran informasi, memori yang tahan lama, dan embed pengetahuan domain. Dulu orang tertawa soal “prompt engineer”, sekarang “context engineer” adalah versi 2.0-nya.
Desain untuk “peningkatan efisiensi”, bukan “penggantian”: biarkan manusia melakukan yang mereka kuasai, agen membersihkan jalan, membuat manusia lebih fokus.
Arsitektur lebih penting daripada memilih model: apakah pakai agen independen, paralel, atau kolaboratif, keputusan ini jauh lebih penting daripada model apa yang dipilih. Pastikan arsitektur benar dulu.
Intervensi dan selesaikan masalah, bukan sekadar lapor dan review: dashboard adalah “kuburan” masalah. Bangun sistem yang memaksa masalah diselesaikan dengan cepat.
Cepat deploy, iterasi terus-menerus: agen terbaik adalah yang sudah berjalan di lingkungan produksi dan terus diperbaiki, bukan yang masih dalam tahap desain. (Dan pastikan kamu mengikuti jadwal waktumu)
Lainnya hanyalah detail.
Teknologi sudah siap, tapi kamu mungkin belum siap.
Dengan memahami ini, kamu bisa memperluas skala bisnis hingga 100 kali lipat.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
AI inteligensi, kunci peningkatan skala bisnis seratus kali lipat
Menulis artikel: vas
Diterjemahkan: AididiaoJP, Foresight News
AI bukanlah sihir, tetapi juga tidak sesederhana “buat program AI, otomatis semua selesai, tunggu hasilnya”. Kebanyakan orang sebenarnya tidak benar-benar memahami apa itu AI.
Dan mereka yang benar-benar mengerti (kurang dari 5%) mencoba membangun sendiri, hasilnya sering gagal. Agen cerdas akan mengalami “ilusi”, lupa langkah apa yang sudah dilakukan di tengah tugas, atau salah memanggil alat saat tidak seharusnya. Saat demo berjalan sempurna, begitu masuk ke lingkungan produksi langsung crash.
Saya sudah mengdeploy program AI selama lebih dari satu tahun. Karir perangkat lunak saya dimulai di Meta, tetapi setengah tahun lalu saya keluar dan mendirikan perusahaan yang khusus mengdeploy agen AI yang siap pakai untuk perusahaan. Sekarang pendapatan tahunan kami sudah mencapai 3 juta dolar AS dan terus bertambah. Ini bukan karena kami lebih pintar dari yang lain, tetapi karena kami terus mencoba-coba, gagal berkali-kali, dan akhirnya menemukan rumus keberhasilan.
Berikut adalah semua yang saya pelajari selama membangun agen cerdas yang benar-benar bisa digunakan. Apapun tingkat keahlianmu—pemula, ahli, atau di antara keduanya—pengalaman ini seharusnya relevan.
Pelajaran pertama: Konteks adalah segalanya
Ini mungkin terdengar sangat jelas, mungkin juga sudah sering kamu dengar. Tapi karena sangat penting, maka perlu ditekankan berulang kali. Banyak orang mengira membangun agen cerdas hanya menghubungkan berbagai alat: pilih model, buka akses database, lalu lepas tangan. Pendekatan ini akan langsung gagal, karena beberapa alasan:
Agen tidak tahu apa yang penting. Ia tidak tahu apa yang terjadi lima langkah sebelumnya, hanya melihat langkah saat ini, lalu menebak apa yang harus dilakukan selanjutnya (sering salah tebak), dan akhirnya mengandalkan keberuntungan.
Konteks, seringkali, adalah perbedaan mendasar antara agen bernilai jutaan dan agen yang tidak berharga sama sekali. Kamu perlu fokus dan mengoptimalkan aspek-aspek berikut:
Apa yang diingat agen: tidak hanya tugas saat ini, tetapi juga seluruh riwayat yang menyebabkan kondisi saat ini. Misalnya saat memproses invoice abnormal, agen perlu tahu: bagaimana abnormalitas itu dipicu, siapa yang mengajukan invoice asli, kebijakan apa yang berlaku, bagaimana penanganan masalah terakhir dengan vendor tersebut. Tanpa riwayat ini, agen hanya menebak-nebak, yang bahkan lebih buruk dari tidak punya agen sama sekali. Karena jika manusia yang menangani, masalah itu mungkin sudah selesai sejak lama. Ini juga menjelaskan mengapa ada yang mengeluh “AI benar-benar sulit digunakan”.
Bagaimana informasi mengalir: saat kamu punya beberapa agen, atau satu agen yang menangani proses multi-langkah, informasi harus ditransfer secara akurat di setiap tahap, tidak boleh hilang, rusak, atau disalahartikan. Agen yang bertugas mengklasifikasi permintaan harus mengirimkan konteks yang bersih dan terstruktur ke agen yang menyelesaikan masalah. Jika transfer tidak rapi, hasilnya akan kacau. Ini berarti setiap bagian harus memiliki input dan output yang terstruktur dan dapat diverifikasi. Contohnya adalah fungsi /compact di Claude Code, yang bisa mentransfer konteks antar sesi LLM berbeda.
Pemahaman agen tentang domain bisnis: agen yang memeriksa kontrak hukum harus tahu bagian mana yang penting, risiko apa yang diperkirakan, dan kebijakan perusahaan yang berlaku. Kamu tidak bisa hanya memberi dokumen dan berharap agen bisa memahami poin penting sendiri, itu tanggung jawabmu. Tanggung jawabmu juga termasuk menyediakan sumber daya secara terstruktur agar agen memiliki pengetahuan domain yang cukup.
Kinerja buruk dalam pengelolaan konteks terlihat dari: agen mengulang panggilan alat yang sama karena lupa sudah mendapatkan jawaban; atau memanggil alat yang salah karena menerima informasi yang salah; atau membuat keputusan yang bertentangan dengan langkah sebelumnya; bahkan setiap kali menganggap tugas sebagai hal baru, mengabaikan pola yang jelas dari tugas serupa sebelumnya.
Pengelolaan konteks yang baik membuat agen seperti seorang pakar bisnis berpengalaman: mampu menghubungkan berbagai informasi tanpa perlu kamu jelaskan secara eksplisit hubungan antar data tersebut.
Konteks adalah kunci untuk membedakan agen yang hanya bisa demo dan agen yang benar-benar berjalan di lingkungan produksi dan menghasilkan output.
Pelajaran kedua: Agen AI adalah pengganda hasil
Pandangan yang salah: “Dengan adanya ini, kita tidak perlu lagi merekrut orang.”
Pandangan yang benar: “Dengan ini, tiga orang bisa melakukan pekerjaan yang dulu dilakukan oleh lima belas orang.”
Agen pasti akan menggantikan sebagian pekerjaan manusia, mengakui hal ini hanyalah kebohongan diri. Tapi sisi positifnya adalah: agen tidak akan menggantikan penilaian manusia, melainkan menghilangkan berbagai gesekan yang muncul dari penilaian manusia, seperti mencari data, mengumpulkan informasi, cross-check, merapikan format, mendistribusikan tugas, mengingatkan tindak lanjut, dan lain-lain.
Contohnya: tim keuangan tetap perlu membuat keputusan terkait abnormalitas, tetapi dengan agen, mereka tidak perlu lagi menghabiskan 70% waktu minggu tutup buku untuk mencari dokumen yang hilang, melainkan bisa memanfaatkan waktu itu untuk menyelesaikan masalah sebenarnya. Agen menyelesaikan semua pekerjaan dasar, manusia hanya melakukan persetujuan akhir. Berdasarkan pengalaman saya melayani klien, kenyataannya adalah: perusahaan tidak akan melakukan PHK karena ini. Pekerjaan karyawan akan bertransformasi dari operasi manual yang membosankan ke tugas yang lebih bernilai, setidaknya untuk saat ini. Tentu saja, dalam jangka panjang, seiring perkembangan AI, situasi ini bisa berubah.
Perusahaan yang benar-benar mendapatkan manfaat dari agen adalah yang tidak hanya ingin mengeluarkan manusia dari proses, tetapi yang menyadari bahwa sebagian besar waktu karyawan dihabiskan untuk “pekerjaan pendukung” dan bukan bagian yang benar-benar menciptakan nilai.
Dengan mendesain agen sesuai pola ini, kamu tidak perlu lagi berdebat soal “akurasi”: biarkan agen melakukan apa yang ia kuasai, manusia fokus pada bidangnya.
Ini juga berarti kamu bisa lebih cepat deploy dan operasikan. Tidak perlu agen menangani semua situasi ekstrem, cukup tangani yang umum dan serahkan yang kompleks dan abnormal ke manusia—dengan konteks yang cukup agar manusia bisa cepat menyelesaikan. Setidaknya, untuk tahap ini, begitulah seharusnya.
Pelajaran ketiga: Manajemen memori dan status
Bagaimana agen menyimpan informasi dalam satu tugas dan antar tugas menentukan apakah ia bisa beroperasi secara skala besar.
Ada tiga pola umum:
Agen independen: menangani seluruh alur kerja dari awal sampai akhir. Ini paling mudah dibangun karena semua konteks ada di satu tempat. Tapi seiring panjangnya proses, manajemen status menjadi tantangan: agen harus mengingat keputusan di langkah ketiga, saat mencapai langkah kesepuluh harus menggunakannya. Jika jendela konteks penuh, atau struktur memorinya tidak tepat, pengambilan keputusan di kemudian hari akan kekurangan informasi awal, menyebabkan kesalahan.
Agen paralel: memproses bagian berbeda dari masalah secara bersamaan. Lebih cepat, tapi menimbulkan masalah koordinasi: bagaimana menggabungkan hasil? Jika dua agen menghasilkan kesimpulan yang bertentangan, apa yang harus dilakukan? Harus ada protokol yang jelas untuk mengintegrasikan informasi dan menyelesaikan konflik. Biasanya perlu ada “wasit” (manusia atau LLM lain) untuk mengatasi konflik atau kondisi balapan.
Agen kolaboratif: menyerahkan pekerjaan secara berurutan. Agen A mengklasifikasi, lalu mengirim ke B untuk riset, kemudian ke C untuk eksekusi solusi. Pola ini cocok untuk alur kerja yang memiliki tahapan jelas, tapi transfer antar agen paling rawan masalah. Apa yang dipelajari agen A harus dikirim ke agen B dalam format yang bisa langsung digunakan.
Kesalahan umum adalah menganggap pola ini sebagai “solusi implementasi”. Padahal, ini adalah keputusan arsitektur yang langsung menentukan batas kemampuan agenmu.
Misalnya kamu ingin membangun agen untuk persetujuan kontrak penjualan, harus diputuskan: apakah satu agen bertanggung jawab penuh? Atau buat agen routing yang membagi tugas ke agen peninjauan harga, peninjauan hukum, persetujuan manajemen, dan lain-lain? Hanya dengan memahami proses bisnis nyata di baliknya, kamu bisa mengajarkan proses ini ke agenmu.
Bagaimana memilih? Tergantung kompleksitas tiap tahap, berapa banyak konteks yang perlu dipindahkan antar tahap, dan apakah setiap tahap harus kolaborasi real-time atau berurutan.
Kalau arsitekturnya salah, kamu bisa menghabiskan berbulan-bulan untuk debugging masalah yang sebenarnya bukan bug. Itu adalah kesalahan desain, masalah yang ingin kamu selesaikan, dan ketidaksesuaian arsitektur solusi.
Pelajaran keempat: Intervensi aktif terhadap abnormalitas, bukan laporan pasca kejadian
Saat membangun sistem AI, reaksi pertama banyak orang adalah: buat dashboard, tampilkan informasinya, biar semua tahu apa yang terjadi. Tolong, jangan lagi buat dashboard.
Dashboard tidak berguna.
Tim keuangan sudah tahu ada dokumen hilang, tim penjualan juga tahu ada kontrak yang terjebak di bagian hukum.
Agen harus langsung mencegah masalah saat terjadi, dan mengalihkan ke orang yang tepat untuk menyelesaikan, sekaligus menyediakan semua informasi yang dibutuhkan, lalu langsung eksekusi.
Invoice datang tapi dokumen tidak lengkap? Jangan cuma catat di laporan. Segera tandai, cari tahu siapa yang harus melengkapi dokumen, dan kirimkan masalah lengkap beserta konteksnya (vendor, jumlah, kebijakan, apa yang kurang). Sekaligus hentikan transaksi masuk sampai masalah terselesaikan. Langkah ini sangat penting, kalau tidak, masalah akan “bocor” ke seluruh organisasi, dan kamu tidak sempat memperbaikinya.
Persetujuan kontrak lebih dari 24 jam belum ada kejelasan? Jangan tunggu rapat mingguan. Otomatis naikkan level, lampirkan detail transaksi, agar yang menyetujui bisa cepat memutuskan tanpa harus cek sistem di mana-mana. Harus ada rasa urgensi.
Vendor tidak memenuhi milestone tepat waktu? Jangan tunggu orang lain yang menyadari. Otomatis aktifkan rencana darurat, dan mulai proses penanganan sebelum masalah membesar.
Tugas agen AI-mu adalah: membuat masalah tidak bisa diabaikan, dan menyelesaikannya dengan sangat mudah.
Langsung ungkap masalah, bukan hanya lewat dashboard.
Ini berlawanan dengan cara kebanyakan perusahaan menggunakan AI: mereka pakai AI untuk “melihat” masalah, sementara kamu harus pakai AI untuk “memaksa” menyelesaikan masalah, dan harus cepat. Setelah tingkat keberhasilan penyelesaian masalah mendekati 100%, baru pertimbangkan buat dashboard.
Pelajaran kelima: Ekonomi agen AI vs SaaS umum
Perusahaan terus membeli SaaS yang tidak digunakan karena alasan tertentu.
SaaS mudah dibeli: ada demo, ada penawaran, ada checklist kebutuhan yang bisa dicentang. Kalau disetujui, dianggap proses berjalan (walaupun sering tidak begitu).
Pembelian SaaS AI paling buruk adalah: seringkali hanya dipajang begitu saja. Tidak terintegrasi dengan alur kerja nyata, jadi cuma jadi sistem lain yang harus login. Kamu dipaksa migrasi data, sebulan kemudian cuma jadi vendor lain yang harus dikelola. Setelah 12 bulan, diabaikan, tapi kamu tidak bisa lepas karena biaya switching terlalu tinggi, jadilah “hutang teknologi”.
Sedangkan AI yang dibangun sendiri dari sistem yang ada akan menghindari masalah ini.
Berjalan di dalam alat yang sudah kamu pakai, tidak menciptakan platform kerja baru, malah mempercepat pekerjaan yang ada. Agen menyelesaikan tugas, manusia hanya melihat hasilnya.
Biaya sebenarnya bukan “biaya pengembangan vs biaya lisensi”, tetapi lebih ke logika sederhana:
SaaS menimbulkan “hutang teknologi”: setiap beli alat baru, bertambah satu integrasi yang harus dipelihara, satu sistem yang akan usang, satu vendor yang mungkin diakuisisi, diubah, atau ditutup.
Membangun agen sendiri menimbulkan “kemampuan”: setiap perbaikan membuat sistem lebih pintar, setiap alur kerja baru memperluas kemungkinan. Investasi ini adalah pertumbuhan majemuk, bukan depresiasi seiring waktu.
Itulah sebabnya selama setahun terakhir saya selalu bilang: SaaS AI umum tidak punya masa depan. Data industri juga membenarkan: sebagian besar perusahaan yang beli SaaS AI berhenti pakai dalam 6 bulan dan tidak melihat peningkatan produktivitas. Yang benar-benar mendapatkan manfaat dari AI adalah perusahaan yang punya agen kustom, baik yang dikembangkan sendiri maupun dari pihak ketiga.
Inilah mengapa perusahaan yang menguasai agen sejak awal akan memiliki keunggulan struktural jangka panjang: mereka membangun infrastruktur yang semakin kuat. Yang lain cuma menyewa alat yang suatu saat harus diganti. Di era perubahan cepat ini, setiap minggu yang terbuang adalah kerugian besar bagi peta jalan produk dan bisnis secara keseluruhan.
Pelajaran keenam: Deploy harus cepat
Kalau rencana proyek AI-mu butuh setahun baru bisa jalan, itu sudah kalah.
Perencanaan tidak bisa mengikuti perubahan. Alur kerja yang dirancang mungkin tidak sesuai kenyataan, dan edge case yang tidak terduga seringkali paling penting. Setelah 12 bulan, dunia AI bisa berubah total, dan apa yang kamu buat mungkin sudah usang.
Maksimal 3 bulan, harus sudah masuk ke lingkungan produksi.
Di era informasi yang meledak ini, kemampuan sejati adalah: tahu cara memanfaatkan informasi secara efektif, dan berkolaborasi dengannya, bukan melawannya. Harus benar-benar mengerjakan: mengelola tugas nyata, membuat keputusan nyata, dan meninggalkan catatan yang bisa dilacak.
Masalah paling umum yang saya lihat adalah: tim pengembang internal sering memperkirakan proyek AI yang seharusnya selesai 3 bulan menjadi 6–12 bulan. Atau lebih buruk—mengatakan 3 bulan, tapi setelah mulai kerja selalu tertunda karena berbagai “alasan tak terduga”. Itu bukan sepenuhnya salah mereka, dunia AI memang kompleks.
Jadi, kamu perlu engineer yang benar-benar paham AI: mereka mengerti bagaimana AI bisa beroperasi secara skala besar, pernah melihat masalah nyata, dan tahu batas kemampuan serta keterbatasan AI. Saat ini terlalu banyak pengembang “setengah matang” yang mengira AI bisa melakukan segalanya—ini jauh dari kenyataan. Kalau kamu ingin masuk ke bidang AI aplikasi perusahaan, kamu harus menguasai batas kemampuan AI secara solid.
Ringkasan
Membangun agen yang bisa digunakan, kuncinya ada di poin-poin ini:
Konteks adalah segalanya: agen tanpa konteks yang baik hanyalah generator angka acak yang mahal. Pastikan aliran informasi, memori yang tahan lama, dan embed pengetahuan domain. Dulu orang tertawa soal “prompt engineer”, sekarang “context engineer” adalah versi 2.0-nya.
Desain untuk “peningkatan efisiensi”, bukan “penggantian”: biarkan manusia melakukan yang mereka kuasai, agen membersihkan jalan, membuat manusia lebih fokus.
Arsitektur lebih penting daripada memilih model: apakah pakai agen independen, paralel, atau kolaboratif, keputusan ini jauh lebih penting daripada model apa yang dipilih. Pastikan arsitektur benar dulu.
Intervensi dan selesaikan masalah, bukan sekadar lapor dan review: dashboard adalah “kuburan” masalah. Bangun sistem yang memaksa masalah diselesaikan dengan cepat.
Cepat deploy, iterasi terus-menerus: agen terbaik adalah yang sudah berjalan di lingkungan produksi dan terus diperbaiki, bukan yang masih dalam tahap desain. (Dan pastikan kamu mengikuti jadwal waktumu)
Lainnya hanyalah detail.
Teknologi sudah siap, tapi kamu mungkin belum siap.
Dengan memahami ini, kamu bisa memperluas skala bisnis hingga 100 kali lipat.