Subagent vs Agent Skill: AI Butuh 'Tim Kecil' Buat Tugas Panjang?

Kamu pasti pernah ngalamin: suruh AI ngerjain proyek panjang — misalnya bikin aplikasi full stack dari nol sampai deploy — dan di tengah jalan dia mulai lupa instruksi awal, salah referensi variabel, atau bikin keputusan yang kontradiktif. Masalahnya classic: context window penuh, reasoning quality turun drastis. Peneliti dari arXiv baru-baru ini drop paper yang ngeliatin solusi lain: jangan load semua skill ke satu konteks, tapi spawn 'subagent' yang punya window sendiri. Konsepnya kayak kamu delegasiin kerja ke tim kecil, masing-masing punya ruang kerjanya sendiri, nanti hasilnya baru dikumpulin ke 'manajer' utama.

Kenapa skill biasa mulai nggak cukup

Sekarang mayoritas framework AI agent pakai pendekatan 'agent skill': kamu siapin paket skill — berisi instruksi, script, resource — terus load semuanya ke context window agent utama. Pas tugas pendek, ini work banget. Tapi pas horizon tugas panjang, context window jadi penuh sama ribuan token instruksi, history chat, dan output intermediate. Akibatnya? Model jadi 'pusing', attention mechanism kebagian, dan reasoning quality nosedive. Paper ini bilang eksplisit: semakin banyak info yang numpuk di satu konteks, semakin brittle performanya. Bayangin kamu coba inget 50 halaman manual sambil ngerjain coding — pasti kelupaan detail penting.

Subagent: konsep 'tim kecil' di dalam AI

Approach subagent beda fundamental: skill package nggak di-load ke main context. Sebaliknya, agent utama spawn subagent baru untuk tiap subtask. Subagent ini dapet context window fresh, bersih, cuma berisi instruksi dan data yang relevan buat subtask itu doang. Dia kerjain, return hasilnya (output yang udah didefinin kontrak input-output-nya), trus main agent lanjut. Kayak kamu suruh junior developer handle module auth, junior lain handle database, kamu cuma review hasil merge-nya. Penelitiannya tunjukin: kalau skill package punya kontrak input-output yang jelas dan instruksi prosedural yang lengkap, subagent execution consistently outperforms agent-skill execution di tugas long-horizon.

Data eksperimen di paper ini cukup convincing. Di benchmark yang dirancang buat tugas multi-step dengan horizon panjang, subagent approach berhasil complete rate lebih tinggi, error rate lebih rendah, dan — yang penting — konsisten di berbagai tipe task. Kenapa? Soalnya setiap subagent start dari 'clean slate', nggak dibebani history yang nggak relevan. Main agent cuma perlu track high-level plan dan koordinasi, nggak perlu mikirin detail implementasi tiap step. Ini mirip pattern hierarchical planning yang udah lama dipakai di robotics dan multi-agent systems, tapi sekarang diaplikasiin ke LLM agent architecture.

Trade-off: overhead komunikasi

Tapi nggak ada gratis lunch. Paper ini jujur nunjukin trade-off: subagent butuh token tambahan buat koordinasi. Main agent harus serialize task description, kirim ke subagent, terima response, parse, lanjut ke step berikutnya. Komunikasi bolak-balik ini makan token — dan token berarti biaya (cost) dan latensi. Di eksperimen, overhead komunikasi bisa sampe 15-30% tambahan token dibanding single-context approach. Jadi kalau tugasnya pendek atau simple, overhead ini nggak worth it. Skill loading biasa masih lebih efisien. Subagent shine kalau tugasnya benar-benar kompleks, multi-stage, dan butuh isolation konteks yang ketat.

Jadi, kapan pakai yang mana?

Practical takeaway buat kamu yang bangun AI agent: evaluasi dulu horizon dan kompleksitas tugas. Kalau tugas pendek (< 10 step), deterministik, dan skill-nya reusable tanpa butuh banyak context — pakai agent skill loading biasa. Lebih cepat, lebih murah, simpler to debug. Tapi kalau tugas long-horizon (20+ step), punya banyak decision point, butuh reasoning yang deep di tiap stage, dan skill packages punya kontrak I/O yang well-defined — subagent approach worth the overhead. Bonus: subagent juga bikin debugging lebih gampang karena kamu bisa inspect konteks tiap subagent secara terpisah, nggak perlu scroll ribuan token di satu conversation log.

• Tugas pendek & simple → agent skill loading (lebih efisien)
• Tugas long-horizon & kompleks → subagent (lebih robust)
• Skill butuh kontrak I/O jelas → subagent performa terbaik
• Budget token terbatas → pertimbangkan overhead komunikasi