Bayangkan kamu punya satu developer jagoan. Pintar, cepat, tapi tetap satu orang. Mau secepat apapun dia ngetik, dia cuma bisa kerjain satu hal dalam satu waktu. Sekarang bayangkan dia bisa mendadak “membelah diri” jadi lima orang, masing-masing fokus di satu bagian, saling ngobrol, saling koreksi.
Itulah yang baru saja terjadi di Claude Code.
Fitur baru ini namanya Agent Teams, atau kalau di komunitas developer sering disebut Swarms. Bukan lagi satu AI yang kerja sendirian dari A sampai Z. Tapi satu AI “lead” yang bisa bikin tim, bagi tugas, lalu biarkan setiap anggota tim kerja barengan. Masing-masing punya konteks sendiri, bisa saling kirim pesan, bahkan bisa saling bantah pendapat satu sama lain.
Kedengarannya kayak fiksi ilmiah? Bukan. Ini udah bisa dicoba sekarang.
Kenapa Satu Agent Aja Nggak Cukup?
Kamu pasti pernah ngalamin ini. Minta Claude refactor authentication di tiga service sekaligus. Awalnya oke, langkahnya rapi. Tapi makin ke belakang, konteksnya makin kabur. Detail dari langkah kedua mulai bocor ke langkah kelima. Akhirnya? /clear, mulai dari nol. Lagi dan lagi.
Ini bukan salah Claude-nya. Ini sifat dasar LLM: makin banyak informasi di context window, makin susah dia fokus ke yang penting sekarang.
Coba pikir gini: tim manusia juga kerja dengan cara yang sama, kan? Kita nggak pernah ngajak backend engineer duduk di code review frontend. Kita nggak CC seluruh kantor di setiap thread Slack. Spesialisasi itu soal fokus, bukan soal kemampuan.
Agent Teams ngaplikasiin prinsip yang sama. Setiap agent dapet scope yang sempit dan konteks yang bersih. Agent testing cuma pegang urusan testing, dia nggak perlu baca catatan rapat planning tiga jam yang lalu. Agent security review nggak perlu pusing soal optimasi performa.
Hasilnya? Output lebih tajam di setiap bagian. Quality check yang jalan sendiri-sendiri. Kalau satu agent gagal, yang lain tetap jalan.
Tapi ada syaratnya. Ini cuma works kalau task-nya di-scope dengan bener. “Buatkan aku aplikasi” itu resep buat bakar token. “Implementasi lima API endpoint ini sesuai spec berikut” … nah, itu baru ngomong.
Cara Kerjanya: Lead, Teammates, dan Inbox
Setup-nya sebenernya simpel.
Satu sesi Claude Code jadi Team Lead. Dia yang spawn Teammates, masing-masing instance Claude Code yang fully independent dengan context window sendiri. Ada shared task list dengan dependency tracking, sistem inbox buat ngobrol antar-agent, dan teammates bisa ambil task sendiri begitu mereka selesai.
Ini beda jauh dari subagent yang udah ada sebelumnya. Subagent itu “pekerja” yang lapor hasil ke satu parent, mereka nggak bisa ngobrol satu sama lain. Agent Teams? Ini kolaborasi beneran. Teammates bisa share temuan, challenge pendekatan satu sama lain, dan koordinasi sendiri tanpa harus selalu lewat lead.
Trade-off-nya jelas: biaya token lebih gede karena setiap teammate itu instance Claude terpisah.
Kapan pakai subagent? Kalau kamu butuh pekerja fokus yang cuma perlu kasih hasil akhir. Kapan pakai agent teams? Kalau teammates perlu diskusi, saling koreksi, dan koordinasi mandiri.
Kapan Fitur Ini Beneran Berguna?
Beberapa pola yang beneran nendang:
Debugging dengan hipotesis berlawanan. Spawn lima teammates, masing-masing investigasi teori berbeda soal kenapa app crash. Biarkan mereka saling bantah. Ini jauh lebih efektif daripada investigasi satu-satu. Kenapa? Karena begitu kamu eksplorasi satu teori duluan, investigasi selanjutnya pasti bias ke arah situ. Kalau paralel, nggak ada yang ke-anchor.
Code review paralel dari sudut pandang beda. Satu teammate fokus security, satu cek performa, satu validasi test coverage. Satu reviewer biasanya cenderung gravitasi ke satu jenis masalah. Kalau dipecah, setiap aspek dapet perhatian penuh.
Fitur yang nyentuh banyak layer. Frontend, backend, dan test, masing-masing dipegang teammate berbeda. Tiga agent kerja paralel dengan fokus penuh, bukan satu agent yang terus-terusan pindah-pindah konteks.
Riset dan eksplorasi. Beberapa teammates investigasi pendekatan berbeda barengan, share temuan, lalu pilih jalur terbaik. Hasil risetnya langsung masuk ke konteks implementasi, nggak ada “telepon rusak”.
Mulai dari Mana?
Aktifkan dulu di settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Lalu tinggal bilang ke Claude pakai bahasa natural:
“Aku lagi desain CLI tool buat tracking TODO comments. Buat agent team: satu fokus UX, satu arsitektur teknis, satu jadi devil’s advocate.”
Claude langsung bikin tim, spawn teammates, bagi tugas, dan sintesis temuan. Di terminal kamu, bisa liat semua teammates dan apa yang mereka kerjakan.
Kamu juga bisa eksplisit soal strukturnya:
“Buat tim 4 teammates untuk refactor modul-modul ini secara paralel. Pakai Opus untuk setiap teammate.”
Cara Ngontrol Tim
Display modes. Dua pilihan. In-process (default), semua teammates jalan di terminal utama kamu. Pakai Shift+Up/Down buat pilih teammate, ketik buat kirim pesan langsung. Atau Split panes via tmux/iTerm2, setiap teammate punya panel sendiri, kamu bisa liat output semua orang sekaligus.
Plan approval. Buat kerjaan yang riskan, kamu bisa minta teammate bikin rencana dulu sebelum eksekusi. Teammate kerja di mode read-only sampai lead setuju pendekatannya. Ditolak? Revisi, submit ulang.
Delegate mode. Tekan Shift+Tab buat ngebatesin lead ke koordinasi doang: spawn, messaging, shutdown teammates, dan manage task. Nggak boleh sentuh kode. Ini buat mencegah masalah klasik: lead malah sibuk ngerjain sendiri alih-alih tunggu teammates selesai.
Chat langsung ke teammate. Setiap teammate itu sesi Claude Code penuh. Kamu bisa kirim pesan ke siapapun langsung tanpa lewat lead.
Yang Harus Diwaspadai
Ini masih experimental. Jujur soal kekurangannya:
Lead kadang “gatal” dan ngerjain sendiri alih-alih delegasi. Solusinya: bilang eksplisit “tunggu teammates selesai dulu” atau aktifin delegate mode.
Nggak ada session resumption buat in-process teammates. /resume dan /rewind nggak balikin teammates. Setelah resume, lead mungkin coba kirim pesan ke teammates yang udah nggak ada. Spawn yang baru aja.
Status task bisa telat ke-update. Teammates kadang lupa tandain task selesai, jadi task yang tergantung sama itu jadi tertahan. Cek manual apa kerjaannya udah beneran kelar.
Satu tim per sesi, nggak bisa nested. Lead kelola satu tim. Teammates nggak bisa spawn tim sendiri. Ini disengaja biar nggak jadi rekursi tanpa batas, token meledak, dan pengawasan hilang.
Biaya token naik seiring jumlah teammates. Buat task rutin, satu sesi biasa lebih hemat. Multi-agent baru worth it buat kerjaan gede yang bisa diparalelkan.
Paralel dengan Manajemen Tim Manusia
Ini yang menarik. Skill yang bikin seseorang jadi engineering manager yang bagus ternyata langsung kepake buat orkestrasi agent.
Ukuran task penting. Terlalu kecil, overhead koordinasi lebih gede daripada kerjaannya. Terlalu besar, teammates kerja terlalu lama tanpa checkpoint. Sweet spot-nya: unit mandiri yang ada deliverable jelasnya. Lima sampai enam task per teammate biasanya pas.
Ownership file penting. Dua teammates edit file yang sama? Siap-siap ada yang ketimpa. Pecah kerjaan supaya setiap teammate punya set file sendiri. Prinsipnya sama kayak ngatur boundary di tim manusia buat hindarin merge conflict.
Konteks loading penting. Teammates dapet CLAUDE.md, MCP servers, dan skills secara otomatis. Tapi mereka nggak dapet conversation history dari lead. Jadi brief-nya harus spesifik:
“Spawn security reviewer teammate dengan prompt: ‘Review authentication module di src/auth/ untuk vulnerability. Fokus ke token handling, session management, dan input validation. App pakai JWT tokens di httpOnly cookies. Laporkan issues dengan severity rating.‘”
Makin spesifik brief-nya, makin bagus output-nya. Sama kayak biasanya. Cuma sekarang kamu nulis brief untuk tim, bukan satu orang.
Satu Peringatan Penting
Ada sesuatu yang menggoda dari ngeliat agents kerja paralel. Metrik aktivitasnya keliatan impressive: commits per jam, task paralel yang selesai, baris kode yang disentuh.
Tapi aktivitas nggak selalu sama dengan value.
Risiko multi-agent system: gampang banget ngasilin kode dalam jumlah besar dengan sangat cepat. Kode itu tetap harus bener, maintainable, dan beneran nyelesaiin masalah. Pernah liat developer yang malah lebih banyak habis waktu konfigurasi pola orkestrasi daripada mikirin apa yang mereka bangun? Jangan jadi orang itu.
Biarkan masalah yang nentuin tools-nya, bukan sebaliknya. Kalau satu agent di sesi fokus bisa selesain lebih cepet, pakai itu. Kalau kamu butuh spesialis paralel, baru pakai agent teams.
Langkah Praktis Buat Mulai
Kalau kamu baru pertama kali main multi-agent, mulai kecil dulu.
Mulai dari riset dan review. Task yang punya batas jelas dan nggak perlu nulis kode. Review PR dari tiga sudut pandang, riset library, investigasi bug dengan teori berlawanan. Ini ngasih liat nilai eksplorasi paralel tanpa pusing koordinasi perubahan kode.
Lalu coba fitur yang nyentuh banyak layer. Frontend, backend, dan test masing-masing dipegang teammate berbeda. Batasnya jelas, deliverable-nya terang.
Baru scale ke refactor gede. Beberapa service, implementasi paralel setelah fase desain bareng. Di sinilah kompresi waktu kerasa banget. Kerjaan yang biasanya butuh berhari-hari kalau dikerjain satu-satu, bisa kelar dalam beberapa jam eksekusi paralel plus review.
Skill intinya bukan nulis lebih sedikit kode. Skill intinya adalah mecah masalah jadi bagian-bagian yang bisa dikerjain agent teams secara paralel. Tau apa yang mau dibangun, tau kayak gimana “bener” itu, dan tau cara verifikasi hasilnya.
Tools-nya udah ada. Tinggal pake dengan bener.
Referensi: Artikel asli oleh Addy Osmani | Dokumentasi Claude Code Agent Teams