Kebalikan dari technical debt yang muncul karena fitur menumpuk tanpa dirapikan, ada masalah lain yang justru terjadi sejak awal, yaitu membangun agent dengan arsitektur rumit untuk kebutuhan yang sebenarnya kecil dan sederhana. Ini sering terjadi karena tergoda ikut pola desain paling canggih yang dibaca dari artikel atau contoh proyek besar, padahal kebutuhan bisnisnya jauh lebih sederhana.
Tanda tanda over-engineering
Beberapa tanda yang cukup jelas, agent punya banyak lapisan tool dan sub-sistem yang jarang benar benar terpakai, waktu setup jauh lebih lama daripada nilai yang dihasilkan, atau tim yang mengurus jadi kesulitan menjelaskan alur kerja sistemnya sendiri karena terlalu banyak cabang kemungkinan yang sebenarnya tidak pernah dipakai.
Kenapa ini merugikan, bukan cuma buang waktu
Sistem yang rumit lebih sulit dipelihara, lebih rentan gagal di titik yang tidak terduga, dan lebih mahal untuk diubah saat kebutuhan bisnis berubah. Untuk kebutuhan sederhana seperti menjawab pertanyaan jam buka atau status pesanan, sistem dengan banyak lapisan justru menambah titik kegagalan tanpa manfaat sepadan.
Mulai dari kebutuhan, bukan dari teknologi
Cara paling aman menghindari over-engineering adalah memulai dari pertanyaan sederhana, apa masalah nyata yang mau diselesaikan, lalu membangun bagian paling minim yang cukup untuk menyelesaikan itu. Kalau kebutuhannya baru menjawab lima jenis pertanyaan berulang, sistem prompt sederhana tanpa banyak tool eksternal biasanya sudah cukup, tidak perlu langsung membangun arsitektur multi-agent lengkap dengan banyak lapisan orkestrasi.
Kompleksitas boleh datang belakangan
Menambah kompleksitas itu jauh lebih mudah dilakukan bertahap saat kebutuhan memang bertambah, dibanding membongkar sistem yang sudah terlanjur rumit sejak awal. Prinsip mulai sederhana lalu tambah secukupnya sesuai kebutuhan nyata, jauh lebih hemat waktu dan biaya dibanding membangun semua kemungkinan di depan sebelum tahu mana yang benar benar dipakai.