Kegagalan AI dalam Pengembangan Agen: 6 Pelajaran Berharga dari Omega

M embangun agen AI yang berfungsi optimal bukanlah sekadar mimpi, melainkan sebuah perjalanan penuh tantangan dan pembelajaran. Banyak perusahaan bermimpi tentang otomatisasi penuh dengan kecerdasan buatan, namun realitanya, proses implementasi sering kali diwarnai oleh hambatan tak terduga. Di Netguru, ketika kami memulai pengembangan Omega, agen penjualan AI internal kami, tujuannya sederhana: memangkas tugas-tugas repetitif, mempermudah akses informasi, dan membantu tim penjualan mengelola alur kerja dari kontak pertama hingga penutupan kesepakatan, semuanya tanpa menambah beban penggunaan alat baru.
Dengan kasus penggunaan yang jelas, tumpukan teknologi yang solid, dan model-model kuat sebagai fondasi, kami berpikir telah memiliki semua yang dibutuhkan. Namun, dari fase ideasi ke prototipe, hingga menjadi alat yang digunakan sehari-hari, kami menyadari bahwa membangun agen AI yang andal bukan hanya tentang kemampuan teknis, melainkan tentang menguji apa yang benar-benar bekerja dalam konteks spesifik kami. Omega tidak langsung berhasil dari hari pertama; kemajuannya justru berasal dari serangkaian kegagalan AI yang kami alami. Setiap kesalahan, mulai dari penyempurnaan perintah (prompts) hingga koordinasi antar agen dan penanganan output yang ‘berhalusinasi’, memberikan kami pelajaran berharga untuk terus berinovasi.
Artikel ini akan mengupas enam kegagalan AI fundamental yang kami alami secara langsung saat mengembangkan Omega. Kami akan berbagi detail mendalam tentang apa yang rusak, bagaimana kami mencoba memperbaikinya, mengapa pendekatan tersebut gagal, dan apa yang akhirnya kami lakukan untuk menemukan solusi yang tepat. Dengan memahami pengalaman kami, Anda akan mendapatkan wawasan praktis dan strategi yang terbukti untuk menghindari perangkap umum dalam membangun agen AI Anda sendiri. Ini adalah kisah nyata tentang bagaimana kegagalan membentuk kesuksesan, sebuah panduan penting bagi siapa pun yang tertarik pada pengembangan agen AI yang tangguh dan efektif.

Pengenalan Omega: Agen Penjualan AI Internal Netguru

Omega adalah agen AI internal yang kami kembangkan di Netguru untuk mendukung tim penjualan kami secara real-time, terintegrasi langsung di dalam Slack. Ini adalah agen yang sadar konteks, dirancang untuk membantu tim penjualan bertindak lebih cepat dan mengikuti praktik terbaik. Keputusan untuk membangun Omega muncul karena alur kerja penjualan kami yang tersebar di berbagai alat, mulai dari Slack, Google Drive, hingga beragam dokumen dan basis pengetahuan internal. Informasi memang ada, tetapi tidak pernah terkonsolidasi di satu tempat, yang pada akhirnya memperlambat seluruh proses.

Tujuan utama Omega adalah menghemat waktu dan sumber daya dengan mengotomatisasi tugas-tugas berulang, memastikan informasi penting mudah diakses, dan menjaga momentum kesepakatan. Dengan berbekal model bahasa besar (LLM) dan arsitektur modular yang canggih, Omega dirancang untuk menjadi asisten proaktif yang bukan sekadar menjawab pertanyaan, tetapi juga memprediksi kebutuhan dan memberikan dukungan kontekstual yang relevan. Keberadaannya di setiap saluran Slack yang terkait dengan peluang penjualan memungkinkan Omega beroperasi di latar belakang, memantau percakapan dan secara cerdas mengintervensi saat dibutuhkan.

Fungsi inti agen AI ini mencakup beberapa kapabilitas vital, seperti:

• Menghasilkan agenda panggilan ahli yang disesuaikan berdasarkan profil klien dan ringkasan awal.
• Meringkas transkrip dari panggilan penemuan (discovery calls) dan panggilan ahli, memanfaatkan integrasi dengan alat seperti BlueDot.
• Menemukan dokumen relevan dalam folder Google Drive bersama, menghilangkan kebutuhan pencarian manual.
• Menyarankan fitur-fitur penting untuk proposal berdasarkan data historis dan tren sukses.
• Melacak momentum kesepakatan dan memberikan dorongan kepada tim ketika progres melambat.

Di balik semua fungsi ini, Omega tidak dibangun sebagai sistem monolitik. Ia didukung oleh arsitektur modular, cloud-native, yang memungkinkan kami melakukan iterasi dengan cepat dan melakukan skalasi tanpa merusak sistem. Infrastruktur serverless (AWS Lambda) menyediakan eksekusi berlatensi rendah, efisiensi bayar sesuai penggunaan, dan skalasi tanpa hambatan. Integrasi API Slack dan Google Drive memastikan akses data lintas platform yang mulus. Vektor pencarian (vector search) dan embeddings meningkatkan kesadaran kontekstual serta kecepatan respons. Yang paling penting, orkestrasi berbasis AutoGen dengan agen-agen spesifik peran, seperti SalesAgent (menginterpretasikan permintaan), PrimaryAgent (mengeksekusi tugas), DatabaseAgent (mengelola basis pengetahuan internal), dan CriticAgent (meninjau output), memungkinkan sistem yang kuat dan adaptif. Desain black-box ini memungkinkan kami menguji, men-debug, atau memperbarui satu bagian pada satu waktu tanpa mengganggu sisa sistem. Pembangunan Omega menjadi studi kasus nyata dalam menghadapi dan mengatasi kegagalan AI dalam pengembangan agen yang kompleks.

Kegagalan AI #1: Pemilihan Infrastruktur yang Tidak Tepat

Ketika kami pertama kali memulai pengembangan Omega, AWS Lambda tampak seperti pilihan infrastruktur yang sempurna. Sebagai layanan serverless, ia menjanjikan kecepatan deployment yang tinggi dan efektivitas biaya untuk beban kerja yang sifatnya sesekali. Kami membayangkan Omega sebagai serangkaian fungsi kecil yang terpicu oleh peristiwa (event-driven), yang akan menjalankan tugasnya lalu berhenti, dengan biaya minimal. Namun, begitu Omega mulai menangani percakapan penjualan real-time di Slack, batasan-batasan Lambda dengan cepat menjadi jelas dan menimbulkan serangkaian kegagalan AI dalam pengembangan agen yang tidak terduga.

Tantangan AWS Lambda untuk Agen AI Interaktif

Agen AI seperti Omega membutuhkan respons yang sangat cepat, kemampuan untuk menarik konteks dari berbagai alat secara instan, dan koordinasi beberapa sub-agen dalam satu alur kerja. Lambda, yang dirancang untuk pekerjaan cepat dan terisolasi, tidak mampu mengimbangi kompleksitas ini. Beberapa masalah kritis yang muncul antara lain:

• Cold Starts: Penundaan lebih dari 3 detik akibat ‘cold start’ sering terjadi, menyebabkan Slack mengalami timeout dan mengulang permintaan yang sama, mengakibatkan respons ganda dan kebingungan pengguna.
• Respons Duplikat: Karena Slack mengulang permintaan yang timeout, Lambda yang terlambat merespons akan menghasilkan output yang sama dua kali, menciptakan duplikasi pesan yang mengganggu di saluran Slack.
• Batas Eksekusi 15 Menit: Alur kerja multi-agen yang lebih panjang dan kompleks, yang melibatkan banyak interaksi dan pemrosesan data, seringkali terpotong di tengah jalan karena batasan waktu eksekusi 15 menit, menghentikan percakapan atau tugas agen secara prematur.
• Manajemen Status: Lambda tidak memiliki manajemen status bawaan, sehingga kami harus melakukan ‘hack’ atau membuat solusi sementara yang rumit untuk mempertahankan status di antara langkah-langkah alur kerja, menambah kompleksitas dan potensi kesalahan.

Singkatnya, Lambda dibangun untuk pekerjaan yang terpicu peristiwa dan berumur pendek, sementara kasus penggunaan Omega lebih mirip dengan mesin percakapan real-time yang membutuhkan memori, iterasi, dan orkestrasi lintas sistem. Hal ini menunjukkan bahwa pemilihan infrastruktur harus benar-benar sesuai dengan sifat dan kebutuhan spesifik dari agen AI yang dibangun.

Solusi Awal dan Komplikasi Baru

Untuk tetap berada dalam batasan timeout 3 detik Slack, kami menerapkan pola respons dua fase. Fase pertama segera mengembalikan kode 200 OK ke Slack, mengonfirmasi penerimaan permintaan. Fase kedua, yang dilakukan secara asinkron dengan memanggil ulang fungsi Lambda itu sendiri, menangani pemrosesan AI yang sebenarnya. Pendekatan ini menggunakan parameter tambahan untuk menunjukkan bahwa ini adalah waktu untuk memproses tugas AI, bukan mengirim konfirmasi kembali ke Slack.

Namun, solusi ini justru memperkenalkan masalah baru. Eksekusi yang terpisah (orphaned executions) sering terjadi ketika panggilan pertama mengalami timeout, menyebabkan tugas tidak pernah selesai. Tidak ada status persisten di antara langkah-langkah, yang membuat pelacakan alur kerja sangat sulit. Debugging menjadi jauh lebih rumit, terutama ketika alur kerja melibatkan banyak agen. Selain itu, kami harus menonaktifkan percobaan ulang (retries) AWS untuk mencegah pesan Slack duplikat, yang menghilangkan salah satu mekanisme ketahanan bawaan dari layanan cloud. Sebuah perbaikan signifikan yang membantu kami mencapai waktu respons di bawah tiga detik adalah memindahkan impor Python dari bagian atas file ke dalam fungsi-fungsi spesifik, meskipun ini bertentangan dengan rekomendasi PEP 8. Ini mencegah pemuatan banyak modul di awal skrip, memungkinkan Lambda memuat hanya apa yang diperlukan untuk mengirim respons awal ke Slack. Namun, ini hanyalah perbaikan cepat dan bukan solusi arsitektural yang fundamental untuk kegagalan AI dalam pengembangan agen ini.

Transisi Menuju Arsitektur yang Lebih Kuat

Omega bukanlah bot tugas tunggal; ia adalah sistem modular multi-agen yang kompleks. Sebuah percakapan bisa melibatkan lebih dari 20 giliran pesan internal, pencarian embedding vektor, kueri RDS, dan panggilan API eksternal (seperti Google Drive dan Apollo.io). Lambda, dengan sifat tanpa status dan eksekusi singkat, tidak dirancang untuk mempertahankan kompleksitas semacam ini. Oleh karena itu, untuk mengatasi batasan-batasan ini, kami beralih ke AWS Step Functions untuk orkestrasi. Step Functions memberikan apa yang tidak bisa diberikan Lambda: manajemen status yang andal di antara langkah-langkah, penanganan kesalahan bawaan dengan logika percobaan ulang, dan konsol visual untuk melacak bagaimana setiap alur agen berjalan. Ini juga membantu kami menjaga peran setiap agen tetap jelas dan modular, tanpa mengandalkan Lambda yang memanggil dirinya sendiri di latar belakang.

Selain itu, untuk tugas-tugas yang lebih berat yang memerlukan waktu eksekusi lebih lama atau memori lebih banyak, kami juga mulai menguji instance EC2 dan server MCP internal. Ini menyediakan koneksi persisten, kontrol lebih besar atas runtime, dan kinerja yang lebih baik untuk beban kerja yang kompleks dan berbasis kontainer. Pengalaman ini menggarisbawahi pentingnya memilih infrastruktur yang tidak hanya efisien tetapi juga skalabel dan sesuai dengan kebutuhan interaktivitas dan persistensi dari sistem agen AI.

Kegagalan AI #2: Batasan Token dan Ringkasan Percakapan Skala Besar

Salah satu tugas kunci agen AI kami adalah meringkas percakapan penjualan yang terjadi di puluhan saluran Slack setiap hari. Di atas kertas, kedengarannya sederhana: tarik riwayat percakapan, masukkan ke model bahasa besar (LLM), dan kembalikan ringkasan yang rapi. Namun dalam praktiknya, kami dengan cepat menghadapi batasan keras yang pada akhirnya akan dialami oleh setiap pembangun AI: ukuran konteks (context size). Ini adalah kegagalan AI dalam pengembangan agen yang sering terjadi dan membutuhkan pendekatan cerdas.

Dilema Konteks: Mengelola Data Slack yang Berlimpah

Model bahasa seperti GPT-4 hanya dapat menangani sejumlah token terbatas (token bisa berupa kata, bagian kata, atau tanda baca). Percakapan Slack, terutama dalam tim penjualan yang aktif, dapat dengan mudah melampaui batasan ini. Ketika kami mencoba memasukkan seluruh riwayat pesan ke dalam model, kami segera menghadapi dua masalah besar:

• Token Overflow: Model tidak dapat memproses semua input. Pesan-pesan penting sering terpotong atau diabaikan sama sekali, menghasilkan ringkasan yang tidak lengkap atau tidak akurat.
• Halusinasi: Ringkasan yang dihasilkan sering kali menciptakan fakta-fakta yang tidak ada, salah menafsirkan percakapan, atau melewatkan konteks kunci, terutama dalam utas percakapan yang panjang dan terfragmentasi. Ini adalah masalah umum ketika model dipaksa untuk ‘mengisi kekosongan’ informasi.

Tujuan kami adalah memberikan ringkasan yang andal dan mudah dicerna di ratusan saluran potensial setiap hari. Namun, membuang semua pesan mentah langsung ke dalam model jelas bukan jawabannya. Data Slack bersifat ‘berisik’ (noisy), non-linear, dan seringkali mencakup berbagai topik yang berbeda dalam satu utas, menjadikannya tantangan besar bagi model bahasa yang sensitif terhadap konteks.

Strategi Awal dan Keterbatasannya

Awalnya, kami menggunakan pendekatan yang naif: meneruskan sebanyak mungkin pesan Slack yang bisa muat ke dalam jendela konteks model dan membiarkannya melakukan yang terbaik. Ketika pendekatan itu mulai gagal secara konsisten, kami membangun pipeline ringkasan yang secara selektif memproses pesan berdasarkan ambang batas yang ditentukan (MAX_STARTING_MESSAGES). Jika percakapan melebihi ambang batas itu, kami akan meringkas pesan-pesan sebelumnya terlebih dahulu dan menyuntikkan ringkasan tersebut ke dalam konteks agen sebelum melanjutkan dengan pesan-pesan yang lebih baru.

Pendekatan ini memang membantu, tetapi hanya sampai batas tertentu. Kode menjadi rapuh dengan cepat, dan logika kapan serta bagaimana meringkas memerlukan penyetelan konstan. Kami bahkan sempat berdebat apakah agen seharusnya menarik riwayat pesan langsung dari Slack sama sekali, atau apakah ia harus sepenuhnya bergantung pada ringkasan yang disimpan di basis data kami. Perdebatan ini mendorong kami untuk memikirkan kembali arsitektur secara lebih luas. Masalahnya bukan hanya batasan token; itu adalah asumsi bahwa AI dapat menangani aliran data real-time yang besar, berantakan, dan tidak terstruktur tanpa persiapan. Pada kenyataannya, AI membutuhkan jendela konteks yang terkontrol, dengan input yang terstruktur dan relevan pada waktu yang tepat. Tanpa prasyarat, ringkasan berubah menjadi tebak-tebakan berdasarkan pola.

Pipeline Ringkasan yang Efisien dengan Step Functions

Untuk meningkatkan pipeline ringkasan secara signifikan, kami mengevaluasi tiga opsi arsitektur: Step Functions, SQS (Simple Queue Service), dan Hybrid (Step Functions + SQS). Setiap opsi memiliki kelebihan dan kekurangannya. Step Functions menawarkan paralelisme bawaan, pemantauan yang kuat, dan logika percobaan ulang, menjadikannya ideal untuk memvisualisasikan proses ujung-ke-ujung dan melakukan skalasi di banyak saluran. SQS menawarkan pendekatan berbasis antrean yang lebih sederhana untuk memicu pekerjaan ringkasan, tetapi dengan visibilitas yang lebih rendah terhadap alur keseluruhan. Model hibrida menawarkan fleksibilitas dengan mengombinasikan orkestrasi dan pemrosesan modular, meskipun menambahkan lapisan manajemen dan pengujian.

Akhirnya, kami memutuskan untuk menggunakan AWS Step Functions untuk tujuan ini. Setiap malam, pipeline ringkasan berjalan, memeriksa semua saluran Slack tempat Omega aktif. Ia mencari pesan-pesan baru dan memperbarui basis data dengan informasi terkini tentang aktivitas terbaru. Proses ini memastikan bahwa Omega memulai setiap hari dengan basis pengetahuan yang mutakhir dan dapat diakses melalui Database Agent. Kami masih menggunakan sejumlah pesan awal yang ditentukan dan memberikan gambaran singkat tentang hari-hari terakhir, tetapi Omega juga memiliki alat bawaan untuk mengambil informasi tambahan dari basis data saat dibutuhkan, mengurangi ketergantungan pada model untuk memproses riwayat lengkap. Pendekatan ini secara efektif mengatasi masalah batasan token dan mengurangi kegagalan AI dalam pengembangan agen yang disebabkan oleh konteks yang berlebihan, memastikan ringkasan yang lebih akurat dan relevan.

Kegagalan AI #3: Alur Agen yang Terjebak dalam Loop Tak Berujung

Menjawab pertanyaan penjualan mungkin terdengar sederhana, hingga Anda meminta agen AI untuk melakukannya. Bahkan dengan model yang kuat dan konteks yang baik, kami dengan cepat menghadapi salah satu tantangan tersulit dalam desain agen: menyusun alur percakapan. Ini adalah salah satu kegagalan AI dalam pengembangan agen yang paling memakan sumber daya dan frustrasi.

Evolusi dari Agen Tunggal ke Multi-Agen

Kami memulai dengan pengaturan agen tunggal. Ini bekerja dengan baik untuk tugas-tugas yang lugas. Namun, pertanyaan yang lebih kompleks—seperti menghasilkan proposal berdasarkan catatan panggilan, data CRM, dan tolok ukur internal—dengan cepat membuat agen kewalahan. Model tidak dapat berargumentasi di berbagai domain, dan hasilnya menjadi samar, tidak konsisten, atau bahkan salah. Jadi, kami memperluas sistem: kami memperkenalkan beberapa agen khusus—SalesAgent, DatabaseAgent, PrimaryAgent, CriticAgent—dan mulai bereksperimen dengan orkestrasi multi-agen. Saat itulah segalanya menjadi aneh.

Strategi orkestrasi pertama kami menggunakan pendekatan round-robin, bergantian antar agen untuk memajukan percakapan. Pendekatan ini terbukti lambat, menghabiskan banyak token, dan seringkali memerlukan terlalu banyak giliran untuk mencapai kesimpulan. Kami menyadari bahwa memaksakan giliran antar agen secara statis tidak mencerminkan cara manusia berkolaborasi. Selain itu, setiap giliran menambahkan informasi ke jendela konteks yang terus membesar, memperburuk masalah batasan token yang sudah kami alami.

Tantangan Koordinasi dan Loop Infinite

Berikutnya, kami beralih ke model selector, di mana sistem pengendali memilih agen terbaik berikutnya berdasarkan konteks saat ini. Ini memang menyelesaikan beberapa masalah penundaan, tetapi memperkenalkan masalah baru: selektor terus-menerus memilih agen yang sama secara berulang. Dalam beberapa kasus, ini menyebabkan loop tak terbatas di mana agen saling mengoper kontrol tanpa pernah menyelesaikan tugas. Dan karena setiap langkah menambahkan ke riwayat pesan bersama, kami membakar token dengan cepat—terutama di Slack, di mana umpan balik cepat sangat penting.

Kami kemudian mencoba pendekatan berbasis Graphflow, yang dirancang untuk memberi kami lebih banyak kontrol dengan mendefinisikan jalur eksplisit di antara agen-agen. Tetapi bahkan itu pun memiliki masalah: agen tidak selalu dipilih dalam urutan yang diharapkan, logika grafik menjadi sulit dikelola, dan men-debug logika alur terasa seperti mengurai jaring kabel yang tidak terlihat. Masalah intinya bukan hanya tentang memilih agen yang tepat, melainkan tentang merancang arsitektur yang tepat untuk kolaborasi. Model bahasa tidak secara alami berkoordinasi. Jika dibiarkan tidak terkendali, mereka dapat mengulang, mengulang kembali, atau macet. Kami juga menemukan bahwa menambahkan lebih banyak agen tidak menjamin hasil yang lebih baik. Tanpa perutean yang ketat, manajemen token, dan pemisahan peran, mudah untuk berakhir dengan terlalu banyak suara di ruangan dan tidak ada arah yang jelas.

CriticAgent, misalnya, dimaksudkan untuk meningkatkan kualitas dengan meninjau output. Dalam praktiknya, ia sering mengganggu atau memulai ulang alur kerja yang tidak perlu. Kami akhirnya harus bereksperimen dengan menghapusnya sepenuhnya untuk mengembalikan stabilitas sistem. Pengalaman ini mengajarkan kami bahwa kompleksitas tidak selalu berarti efektivitas, dan bahwa desain yang lebih sederhana dan lebih terarah seringkali menghasilkan hasil yang lebih baik dalam menghadapi kegagalan AI dalam pengembangan agen.

Eksperimen Arsitektur untuk Kolaborasi Agen yang Lebih Baik

Saat ini, kami menjalankan eksperimen terstruktur untuk membandingkan dua arsitektur utama guna mengatasi masalah loop dan efisiensi agen. Pendekatan pertama adalah ‘swarm approach’ (pendekatan kawanan), di mana beberapa agen khusus dapat saling mengoper tugas menggunakan konteks bersama dan panggilan alat (tool calls). Pendekatan ini mendukung delegasi yang lebih alami, tetapi berisiko terjadi ‘ping-pong’ antar agen dan pertumbuhan jendela konteks yang tidak terkendali. Pendekatan kedua adalah ‘single-agent + tools’, di mana satu agen utama memanggil agen lain sebagai alat saat dibutuhkan. Opsi ini lebih sederhana, lebih cepat, dan lebih mudah di-debug, meskipun dengan biaya fleksibilitas yang lebih sedikit.

Kedua opsi tersebut menghilangkan konsep ‘agen utama’ dan memperlakukan CriticAgent sebagai ‘alat umpan balik’ opsional daripada peserta pengendali. Kami juga mendefinisikan metrik evaluasi yang jelas (misalnya, tingkat keberhasilan tugas, efisiensi token, latensi) dan menggunakan laporan bug nyata serta tolok ukur dari versi Omega sebelumnya untuk memandu eksperimen. Dengan terus menguji dan menyempurnakan arsitektur orkestrasi, kami berharap dapat membangun sistem agen AI yang lebih cerdas, lebih efisien, dan bebas dari loop tak berujung, sekaligus memastikan bahwa setiap agen memberikan nilai maksimal tanpa menyebabkan kegagalan AI dalam pengembangan agen yang merugikan. Lebih banyak tentang arsitektur multi-agen bisa ditemukan pada dokumentasi Microsoft AutoGen.

Kegagalan AI #4: Melewatkan Riset Mendalam dalam Kasus Penggunaan Kritis

Omega dibangun untuk menangani lebih dari sekadar tugas sederhana; ia diharapkan mampu meringkas panggilan, menghasilkan proposal, dan bahkan membuat laporan ROI satu halaman yang disesuaikan dengan industri klien. Agen ini memiliki akses ke data internal, ringkasan terstruktur, dan konteks CRM. Namun, saat kami mendorong kasus penggunaan tersebut, menjadi jelas bahwa output yang dihasilkan seringkali kehilangan satu lapisan penting: kedalaman. Ini adalah kegagalan AI dalam pengembangan agen yang berkaitan dengan kualitas dan keandalan informasi.

Keterbatasan Pengetahuan Internal Agen AI

Kami berharap AI akan bertindak seperti asisten pintar yang bisa menjawab pertanyaan dengan cepat. Tetapi pada kenyataannya, kami membutuhkan AI untuk berpikir seperti seorang konsultan, dan konsultan tidak menjawab pertanyaan begitu saja. Mereka melakukan riset terlebih dahulu. Di sinilah segalanya mulai salah. Kami meminta Omega untuk menghasilkan studi kasus spesifik industri atau membangun narasi persuasif menggunakan tolok ukur kompetitor. Tanpa akses ke web terbuka atau sumber pengetahuan eksternal, agen hanya mengandalkan data internal, atau yang lebih buruk, mengisi kekosongan dengan halusinasi. Ini menyebabkan output yang dangkal, tidak berdasar, dan seringkali tidak dapat dipercaya dalam skenario berisiko tinggi.

Omega tidak bisa meniru cara manusia memecahkan masalah sulit. Seorang insinyur penjualan, ahli strategi, atau perwakilan penjualan yang nyata melakukan lebih dari sekadar mengingat pengetahuan. Mereka mencari informasi, memverifikasi sumber, dan melakukan pengecekan silang angka sebelum mereka berbicara. Sebuah LLM tunggal, tanpa akses ke pengetahuan eksternal, tidak dapat mereplikasi proses tersebut. Dengan demikian, ketika dihadapkan pada pertanyaan yang membutuhkan pemahaman mendalam tentang tren pasar, data kompetitor, atau riset industri terbaru, agen AI kami hanya bisa menebak-nebak berdasarkan pola internalnya, yang seringkali tidak cukup untuk kebutuhan bisnis yang sebenarnya.

Pentingnya Akses Pengetahuan Eksternal

Pelajaran yang kami petik adalah bahwa AI membutuhkan akses pengetahuan eksternal untuk berargumentasi (reason) dengan benar dalam banyak konteks. Tanpa itu, ia hanya menebak-nebak berdasarkan pola yang ia pelajari dari data latihannya. Ini sangat berbeda dengan kemampuan manusia untuk melakukan riset aktif, mengevaluasi kredibilitas sumber, dan mensintesis informasi dari berbagai domain. Sebuah agen AI yang dimaksudkan untuk mendukung keputusan strategis dalam penjualan tidak bisa dibatasi hanya pada basis pengetahuan yang sudah ada. Ia harus memiliki kemampuan untuk memperluas pemahamannya secara dinamis.

Kegagalan ini menyoroti bahwa dalam kasus penggunaan AI yang berisiko tinggi dan membutuhkan informasi yang selalu terbarui, pengetahuan statis tidak akan cukup. Agen AI harus dilengkapi dengan mekanisme untuk mencari, memverifikasi, dan mengintegrasikan informasi baru dari dunia nyata secara mandiri. Ini bukan hanya tentang memiliki lebih banyak data, tetapi tentang memiliki data yang relevan dan diverifikasi pada saat yang tepat. Mengabaikan aspek ini berarti menerima kegagalan AI dalam pengembangan agen yang terus-menerus menghasilkan output yang kurang mendalam atau bahkan menyesatkan.

Opsi Pengembangan Kapasitas Riset Mendalam

Untuk mengatasi keterbatasan ini, kami kini tengah mengeksplorasi kemampuan Riset Mendalam khusus—alat dan agen yang dirancang secara spesifik untuk melakukan riset multi-langkah berbasis web sebelum menghasilkan output. Kami menguji tiga opsi utama untuk memberikan Omega kemampuan riset eksternal yang dibutuhkan:

1. Azure Deep Research Tool: Opsi ini menawarkan jendela konteks besar (hingga 200K token) dan integrasi yang solid dalam ekosistem Azure. Ini adalah agen riset multi-langkah terstruktur yang dapat menarik data dari web terbuka melalui Bing dan menghasilkan laporan mendalam. Namun, alat ini mahal dan terbatas pada wilayah tertentu.
2. Sonar Deep Research (melalui Perplexity): Pendekatan ini lebih sederhana, berbasis API, dengan biaya lebih rendah dan fleksibilitas lebih besar. Ini mendukung penanganan kutipan (citations) dan lebih mudah diintegrasikan, tetapi memiliki ukuran konteks yang lebih kecil (128K) dan memerlukan akun Perplexity eksternal.
3. Custom Research Agent: Ini adalah pendekatan yang paling fleksibel (dan memakan waktu). Dibangun menggunakan contoh sumber terbuka seperti DeepSeek R1, opsi ini memungkinkan kami untuk menyesuaikan spesialis riset untuk kebutuhan Omega—sepenuhnya dapat dikonfigurasi dan terintegrasi ke dalam sistem multi-agen kami.

Setiap jalur memiliki pertimbangan sendiri: Azure menawarkan konteks tinggi tetapi dengan biaya dan fleksibilitas rendah; Perplexity lebih murah dan sederhana tetapi dengan overhead integrasi; dan membangun kustom memberikan kontrol penuh tetapi membutuhkan waktu pengembangan dan pemeliharaan yang lebih banyak. Pilihan akhirnya akan sangat bergantung pada keseimbangan antara kebutuhan akan kedalaman riset, anggaran, dan kemampuan integrasi dengan arsitektur Omega yang sudah ada, dengan tujuan akhir untuk memastikan Omega dapat memberikan analisis dan rekomendasi yang benar-benar ahli dan berbasis bukti.

Kegagalan AI #5: Mengabaikan Input Visual dalam Pemrosesan Dokumen

Sebagai manusia, kita sangat mengandalkan visual sepanjang waktu. Tabel, tangkapan layar, grafik, dan gambar seringkali membawa lebih banyak makna daripada paragraf teks. Namun dalam versi awal Omega, agen AI kami tidak dapat ‘melihat’ semua itu. Dan itu menciptakan ‘blind spot’ serius yang menyebabkan kegagalan AI dalam pengembangan agen dalam pemahaman dokumen.

Blind Spot AI: Saat Gambar dan Tabel Terabaikan

Ketika tim penjualan kami meminta Omega untuk meringkas pitch deck, mengekstraksi wawasan dari studi kasus, atau menghasilkan proposal menggunakan dokumen PDF, agen AI hanya memproses teks biasa. Ia mengabaikan tabel, melewatkan gambar, dan mengabaikan tata letak visual yang seringkali menjadi inti dari makna dokumen. Beberapa masalah utama yang muncul adalah:

• Tabel Terdistorsi atau Salah Baca: Tabel, yang seharusnya memberikan informasi terstruktur, seringkali diratakan menjadi teks biasa atau disalahartikan, kehilangan struktur dan makna pentingnya.
• Tangkapan Layar dengan Teks Terabaikan: Gambar atau tangkapan layar yang menyematkan teks penting (seperti grafik KPI atau ringkasan metrik) sepenuhnya diabaikan oleh agen AI, sehingga informasi vital tidak terdeteksi.
• Dokumen Visual-Heavy Menghasilkan Ringkasan Dangkal: Dokumen yang kaya visual mengembalikan ringkasan yang tidak memiliki konteks kunci atau salah merepresentasikan makna aslinya, karena sebagian besar informasi pentingnya ada dalam elemen visual.

Omega awalnya dibangun untuk memproses teks. Namun, banyak dokumen bisnis—terutama dalam penjualan—mengandung informasi penting dalam bentuk visual. Tabel perbandingan produk, grafik KPI, atau ringkasan harga sering muncul sebagai gambar atau tata letak terstruktur yang tidak dapat ditangkap oleh analisis teks biasa. Model tidak gagal karena tidak akurat; ia gagal karena tidak dapat memproses jenis konten yang sering diandalkan manusia—tabel, grafik, dan gambar yang membawa konteks esensial. Ini adalah demonstrasi nyata bahwa AI yang hanya berbasis teks tidak cukup untuk aplikasi bisnis yang realistis.

Dampak Informasi Visual yang Hilang

Dampak dari kegagalan AI dalam pengembangan agen untuk memproses visual sangat signifikan. Bayangkan sebuah proposal penjualan yang membandingkan produk Anda dengan kompetitor dalam format tabel. Jika agen AI tidak dapat membaca tabel tersebut dengan benar, ringkasannya akan kehilangan poin-poin perbandingan krusial atau bahkan salah merepresentasikan keunggulan produk Anda. Hal ini tidak hanya mengurangi keandalan Omega tetapi juga merusak kepercayaan pengguna terhadap outputnya. Informasi visual tidak hanya ‘pelengkap’ tetapi seringkali merupakan ‘intisari’ dari sebuah dokumen, terutama dalam konteks penjualan di mana presentasi data yang jelas dan persuasif sangatlah penting. Mengabaikan visual berarti mengabaikan sebagian besar cerita yang ingin disampaikan oleh dokumen tersebut.

Kondisi ini memaksa kami untuk mencari solusi yang mampu menjembatani kesenjangan antara kemampuan pemrosesan teks dan kebutuhan akan pemahaman visual. Tanpa kemampuan ini, agen AI kami akan selalu beroperasi dengan pemahaman yang parsial tentang dokumen, membatasi efektivitasnya dalam mendukung tim penjualan dengan analisis yang komprehensif dan akurat. Kami menyadari bahwa untuk benar-benar menjadi ‘agen pintar’, Omega harus bisa ‘melihat’ dan ‘memahami’ dunia sebagaimana manusia melakukannya, termasuk aspek visual dari informasi.

Solusi Ekstraksi Data Multimodal yang Efektif

Kami mengeksplorasi tiga opsi utama untuk memungkinkan ekstraksi data visual dan terstruktur dari PDF. Opsi pertama adalah Amazon Textract, layanan AWS yang dikelola sepenuhnya dengan akurasi tinggi, terutama untuk tabel dan formulir kompleks. Ini tidak memerlukan infrastruktur dan mudah diintegrasikan, tetapi biayanya per halaman mahal dan berisiko vendor lock-in. Opsi kedua adalah tumpukan sumber terbuka (pdfplumber + OCR), pendekatan DIY menggunakan pdfplumber untuk mengurai tabel dan Tesseract untuk ekstraksi teks berbasis gambar. Ini lebih murah dan fleksibel, tetapi akurasinya dapat bervariasi dan menuntut lebih banyak upaya pengembangan serta pemeliharaan. Opsi ketiga adalah LLM multimodal seperti GPT-4o, pilihan paling modern yang memungkinkan pengumpanan seluruh PDF langsung ke model yang dapat memahami teks dan visual secara bersamaan. Ini secara dramatis menyederhanakan pipeline dan mendukung tata letak kompleks, tetapi mahal dalam penggunaan token dan kurang dapat diprediksi dalam konsistensi output.

Kami juga mempertimbangkan opsi hibrida: mengonversi PDF ke Markdown terstruktur (dengan format tabel dan metadata gambar), lalu meneruskannya ke LLM multimodal. Setelah melakukan riset dan pengujian mendalam terhadap berbagai cara memproses berbagai PDF di dunia nyata, kami mencoba Azure AI Document Intelligence, dan itu langsung berhasil. Hasilnya solid: ia mempertahankan struktur tabel, menarik teks dari gambar, dan menangani tata letak kompleks dengan konsistensi. Karena cocok dengan infrastruktur berbasis Azure kami, Omega dapat dengan mudah mengekstrak data terstruktur dan memasukkannya ke dalam proses hilir. Ini adalah solusi krusial yang mengatasi kegagalan AI dalam pengembangan agen yang berkaitan dengan pemrosesan visual, membuka jalan bagi Omega untuk memahami dokumen secara lebih holistik.

Kegagalan AI #6: Memilih Kerangka Kerja Tanpa Memahami Trade-off

Ketika Anda membangun sistem agen AI dari awal, memilih kerangka kerja yang tepat terasa seperti keputusan taktis. Namun pada kenyataannya, ini adalah keputusan strategis. Dan seperti strategi lainnya, pilihan yang salah dapat memperlambat Anda berbulan-bulan kemudian—tepat ketika Anda perlu bergerak paling cepat. Ini adalah kegagalan AI dalam pengembangan agen yang berakar pada keputusan fundamental di awal proyek.

Dilema Awal Pemilihan Framework AutoGen

Di awal proyek Omega, kami membutuhkan cara untuk membangun dan mengorkestrasi beberapa agen AI tanpa harus menciptakan segalanya dari awal. Kami mencari kerangka kerja yang fleksibel, siap produksi, dan dapat berkembang sesuai kebutuhan kami. Setelah mengevaluasi beberapa opsi, kami memilih AutoGen dan menggunakan API tingkat tingginya, AgentChat, untuk mempercepat pengembangan. AutoGen menawarkan ekosistem yang kaya, integrasi yang baik dengan Azure, dan keseimbangan antara abstraksi dan kontrol, yang membuatnya tampak ideal untuk memulai proyek.

Kerangka kerja ini memang membantu kami menjalankan dasar-dasarnya—mendefinisikan agen, menetapkan peran, dan membangun alur orkestrasi—dengan cepat. Namun, seiring dengan semakin kompleksnya sistem, kami mulai memperhatikan batasan yang memengaruhi kustomisasi, dukungan model, dan debugging. Ketergantungan pada abstraksi tingkat tinggi AgentChat yang awalnya membantu, kini mulai menjadi penghalang ketika kami membutuhkan kontrol lebih granular atau perilaku yang sangat spesifik yang tidak tercakup dalam desain awalnya. Pemilihan kerangka kerja yang tidak mempertimbangkan kebutuhan jangka panjang dan kompleksitas yang akan datang adalah kesalahan umum dalam pengembangan perangkat lunak, dan agen AI tidak terkecuali.

Batasan dan Tantangan dalam Produksi

Kami memilih AutoGen karena ekosistemnya yang kaya, integrasi Azure, dan keseimbangan antara abstraksi dan kontrol. Namun, itu berarti kami harus menerima siklus iterasi yang lebih lambat, trade-off dukungan model, dan beberapa batasan spesifik vendor. Dan meskipun AgentChat membantu kami bergerak cepat di awal, ia tidak dibangun untuk kustomisasi mendalam atau logika tingkat produksi yang kompleks. Semakin kami mencoba memperluasnya, semakin banyak resistensi yang kami temui. Beberapa batasan yang paling menonjol meliputi:

• Dukungan Model Terbatas: Beberapa model tidak didukung secara native, dan pembaruan ke model yang lebih baru memerlukan perubahan pada tumpukan AutoGen seiring berkembangnya keluarga model. Hal ini membatasi kemampuan kami untuk mengadopsi inovasi terbaru dalam LLM.
• Fleksibilitas Berkurang: Kustomisasi menjadi lebih sulit karena semakin banyak kasus ekstrem muncul. Desain AgentChat yang terstruktur seringkali menghalangi penyesuaian yang diperlukan untuk menangani kebutuhan bisnis yang unik atau perilaku agen yang sangat spesifik.
• Debugging yang Tidak Transparan: Pemecahan masalah pada tingkat AgentChat menjadi tantangan ketika proses gagal secara diam-diam di balik layar. Kurangnya visibilitas ke dalam alur kerja internal kerangka kerja mempersulit identifikasi akar masalah dan penerapan perbaikan yang cepat.

Batasan-batasan ini menunjukkan bahwa meskipun kerangka kerja dapat mempercepat pengembangan awal, penting untuk memahami batasan fundamentalnya dan bagaimana hal itu akan memengaruhi skalabilitas dan pemeliharaan jangka panjang. Kegagalan AI dalam pengembangan agen ini mengajarkan kami bahwa investasi waktu dalam riset kerangka kerja yang lebih mendalam di awal proyek dapat menghemat banyak waktu dan tenaga di kemudian hari.

Strategi Jangka Panjang dan Fleksibilitas Framework

Untuk mengatasi batasan-batasan ini tanpa sepenuhnya meninggalkan manfaat ekosistem AutoGen, kami memutuskan untuk tetap menggunakan kerangka kerja ini, tetapi dengan penekanan lebih pada penggunaan AutoGen Core ketika kami membutuhkan lebih banyak kontrol atau stabilitas. Ini memungkinkan kami mempertahankan manfaat dari ekosistem tanpa terkunci dalam abstraksi tingkat tertinggi. Dengan menggunakan komponen yang lebih mendasar, kami mendapatkan fleksibilitas yang lebih besar untuk menyesuaikan perilaku agen dan mengelola alur kerja sesuai kebutuhan spesifik kami.

Kami juga menambahkan strategi fallback dan praktik terbaik untuk memastikan ketahanan dan portabilitas sistem:

• Membangun Wrapper: Kami membuat wrapper di sekitar logika inti untuk mengabstraksikan ketergantungan kerangka kerja tertentu, sehingga jika kami perlu beralih ke kerangka kerja lain di masa mendatang, perubahan yang diperlukan akan minimal.
• Desain Agen Modular: Kami merancang agen dan alur orkestrasi kami sedemikian rupa sehingga secara teori dapat di-porting ke kerangka kerja lain di masa mendatang, memastikan bahwa kami tidak sepenuhnya terikat pada satu platform.
• Memantau Alternatif: Kami terus memantau alternatif yang muncul seperti ADK Google (meskipun masih terlalu muda untuk penggunaan produksi) untuk fleksibilitas jangka panjang.

Pelajaran dari kegagalan AI dalam pengembangan agen ini menegaskan bahwa pemilihan kerangka kerja adalah keputusan strategis yang memerlukan pemahaman mendalam tentang trade-off dan rencana jangka panjang untuk skalabilitas serta pemeliharaan. Keseimbangan antara kecepatan pengembangan awal dan fleksibilitas jangka panjang adalah kunci untuk keberhasilan proyek AI yang berkelanjutan.

Pelajaran Utama dari Kegagalan AI Omega: Menuju Agen AI yang Lebih Cerdas

Membangun Omega bukanlah proses yang bersih dan linier. Pada setiap tahap—mulai dari infrastruktur hingga orkestrasi, batasan konteks hingga pemrosesan visual—kami menghadapi gesekan. Setiap kegagalan AI dalam pengembangan agen memaksa kami untuk memikirkan kembali asumsi dan memperketat lingkaran umpan balik antara apa yang kami inginkan agen lakukan dan apa yang sebenarnya mampu dilakukannya. Pengalaman ini mengukir pelajaran berharga yang membentuk Omega menjadi sistem yang lebih tangguh dan cerdas.

Kami belajar bahwa solusi yang tampak ideal di atas kertas seringkali memiliki batasan serius dalam implementasi dunia nyata. Layanan serverless seperti Lambda, meskipun efisien untuk tugas-tugas terisolasi, tidak selalu merupakan pilihan terbaik untuk logika AI multi-langkah yang stateful dan membutuhkan interaksi real-time yang cepat. Membuang data Slack mentah ke dalam model tidak hanya menciptakan ‘kebisingan’ (noise) tetapi juga menyebabkan halusinasi dan output yang tidak akurat, menekankan pentingnya pra-pemrosesan data dan manajemen konteks yang cerdas. Terlalu banyak agen dalam satu alur kerja, tanpa orkestrasi yang ketat, dapat menyebabkan loop tak terbatas dan pemborosan token yang signifikan, menunjukkan bahwa kesederhanaan dan kejelasan peran agen adalah kunci.

Selain itu, kami menyadari bahwa LLM tunggal tidak dapat bernalar secara mendalam tanpa akses ke alat riset, sama seperti manusia. Pemahaman yang komprehensif seringkali memerlukan kemampuan untuk mencari dan mengintegrasikan informasi dari sumber eksternal. Mengabaikan visual dan data terstruktur dalam dokumen berarti kehilangan inti cerita, karena banyak informasi penting disampaikan melalui tabel, grafik, dan gambar. Terakhir, memilih kerangka kerja terlalu dini tanpa memahami trade-off jangka panjang dapat membatasi keputusan desain yang sulit diubah di kemudian hari, menegaskan pentingnya evaluasi kerangka kerja yang matang.

Pada akhirnya, pembangunan Omega menjadi studi kasus AI tersendiri—sebuah eksperimen tentang apa yang sebenarnya diperlukan untuk menciptakan agen yang berguna. Kegagalan AI dalam pengembangan agen adalah bagian integral dari proses itu, membantu kami menguji, membandingkan, dan pada akhirnya memilih solusi AI yang benar-benar bekerja. Dengan menerapkan pelajaran ini, kami tidak hanya meningkatkan Omega tetapi juga mengumpulkan wawasan yang tak ternilai bagi siapa pun yang berani menjelajahi dunia pengembangan agen AI yang kompleks dan dinamis.

Pertanyaan yang Sering Diajukan (FAQ)

Kesimpulan

Perjalanan membangun agen AI seperti Omega di Netguru adalah bukti bahwa inovasi sejati sering kali lahir dari serangkaian kegagalan dan pembelajaran yang tak henti-hentinya. Setiap kendala, mulai dari pemilihan infrastruktur hingga manajemen konteks, orkestrasi multi-agen, riset mendalam, pemrosesan visual, dan pemilihan kerangka kerja, memberikan wawasan krusial tentang kompleksitas pengembangan AI di dunia nyata. Kami belajar bahwa AI yang efektif bukan hanya tentang algoritma tercanggih, melainkan tentang adaptasi berkelanjutan, pemahaman mendalam terhadap batasan teknologi, dan kemampuan untuk belajar dari setiap kesalahan.
Enam kegagalan AI yang kami alami bukan akhir, melainkan titik awal untuk iterasi dan perbaikan. Mereka mendorong kami untuk merancang sistem yang lebih tangguh, lebih cerdas, dan pada akhirnya, lebih bermanfaat bagi tim penjualan kami. Bagi Anda yang sedang mempertimbangkan atau sedang dalam proses mengembangkan agen AI, ingatlah bahwa kegagalan AI dalam pengembangan agen bukanlah halangan, melainkan peta jalan. Gunakan wawasan yang kami bagikan untuk memandu proyek Anda, hindari perangkap umum, dan bangunlah agen AI yang tidak hanya memenuhi harapan, tetapi juga melampauinya. Jika Anda siap untuk menerapkan pelajaran berharga ini dan ingin mewujudkan agen AI Anda, jangan ragu untuk hubungi kami untuk konsultasi lebih lanjut.