# Cara mendelegasikan tugas besar di Claude Code menggunakan subagent bersarang > Panduan ini membahas fitur v2.1.172 yang memungkinkan subagent Claude Code membuat subagent sendiri hingga kedalaman 5 tingkat. Fitur ini mendukung pendelegasian tugas besar. Source: https://ailoot.ai/blog/id/claude-code-nested-subagents/ Canonical: https://ailoot.ai/blog/id/claude-code-nested-subagents/ Language: id Publisher: Ailoot (https://ailoot.ai/) Translation: guide-232 Revision: sha256-b66023aef14c0b5e3aa994b2d6abaa1f0c9c5df72e0a57b53bb5615424734b29
[Dokumentasi Ailoot](https://ailoot.ai/docs/) — materi referensi tentang penggunaan layanan.
## Apa yang berubah di Claude Code v2.1.172?
Intisari Anthropic merilis Claude Code v2.1.172 dan menghapus aturan berusia dua tahun hanya dengan satu baris di catatan rilis. Kini subagent dapat membuat subagent mereka sendiri, hingga kedalaman 5 tingkat. Fitur ini bukan soal kecepatan atau tambahan CPU. Gagasan utamanya adalah mencegah pekerjaan persiapan yang berisik memenuhi konteks utama Anda.
Jika Anda membaca apa pun tentang agen AI di Claude Code selama beberapa bulan terakhir, Anda pasti pernah melihat frasa yang sama. Frasa itu ada di dokumentasi resmi, di panduan saya [tentang subagent](https://ailoot.ai/blog/id/claude-code-subagents/), dan di analisis setiap pesaing. Bunyinya: “subagent tidak dapat membuat subagent lain.” Per 11 Juni 2026, kalimat itu masih ada di tiga tempat berbeda pada `code.claude.com/docs/en/sub-agents`. Anthropic memang belum memperbaruinya. Pada 10 Juni pukul 20:44 UTC, Claude Code v2.1.172 muncul di GitHub Releases. Butir utama catatan rilis hanya satu baris:
Kini subagent dapat membuat subagent mereka sendiri, hingga kedalaman 5 tingkat.
— Catatan Perubahan Claude Code, https://github.com/anthropics/claude-code/releases/tag/v2.1.172
Rilis yang sama juga memperbaiki bug yang hanya bisa terjadi saat ada nesting: subagent latar belakang tetap disorot sebagai aktif di panel agen setelah subagent bersarang yang diluncurkannya dihentikan. Ini kasus langka ketika dokumentasi resmi masih bertentangan dengan build yang sudah dirilis. Berikutnya saya akan menjelaskan perbedaan nesting dengan subagent paralel, arti “kedalaman 5”, dan tiga skenario yang benar-benar berguna saat ini. ## Apa perbedaan subagent bersarang dengan subagent paralel dan berurutan?
Intisari Jika Anda bingung, Anda tidak sendirian. Paralelisme, rantai, dan nesting adalah tiga topologi yang saling terpisah. Paralelisme berkaitan dengan kecepatan, rantai berkaitan dengan urutan eksekusi, sedangkan nesting membahas hal lain sepenuhnya: menyembunyikan pekerjaan berisik dari jendela utama. Campuradukkan semuanya dan Anda akan menghabiskan token dalam beberapa jam, lalu tidak bisa menemukan sumber kesalahannya.
Saya menghabiskan waktu cukup lama mencoba ketiga pendekatan ini secara langsung. Begini cara saya memahaminya: delegasi memiliki tiga dimensi—lebar, panjang, dan kedalaman. Masing-masing menyelesaikan masalah yang berbeda. **Lebar—subagent paralel.** Chat utama meluncurkan N subagent independen pada tingkat yang sama. Masing-masing mendapat tugas yang sempit, bekerja di jendela terisolasi sendiri, dan hanya mengembalikan hasil. Lebar mengatasi masalah kecepatan: 5 subagent yang bekerja paralel selesai dalam waktu yang dibutuhkan satu subagent untuk mengerjakan hal yang sama secara berurutan. Ini model yang saya bahas dalam panduan [tentang subagent paralel menggunakan worktree](https://ailoot.ai/blog/id/claude-code-parallel-worktree-agents/). **Panjang—rantai subagent.** A bekerja, menyerahkan hasil kepada B, lalu B bekerja dan menyerahkan hasilnya kepada C. Masing-masing melihat masukan dari yang sebelumnya. Panjang menetapkan urutan: B tidak dapat mulai sebelum menerima data dari A. Contoh klasiknya: subagent riset mengumpulkan sumber terlebih dahulu, lalu subagent penyuntingan menulis artikel berdasarkan sumber tersebut, kemudian subagent pemeriksa fakta memeriksa artikel. Ini urutan datar; chat utama memegang keseluruhan alur. **Kedalaman—subagent bersarang.** A meluncurkan B, B meluncurkan C, C meluncurkan D. Setiap anak bekerja di dalam induknya, pada jendela terisolasi sendiri, dan hanya mengembalikan **hasil** kepada induknya. Chat utama tidak melihat apa pun yang terjadi pada anak, cucu, dan cicit. Inilah hal baru di v2.1.172. Kebingungan utamanya adalah orang mengira kedalaman 5 berarti “Anda dapat meluncurkan 5 subagent sekaligus.” Bukan begitu. Kedalaman adalah tingkat vertikal dalam pohon, bukan jumlah anak yang berjalan bersamaan. Pada setiap tingkat bisa ada satu atau seratus subagent. Kedalaman 5 berarti rantai delegasi dapat turun 5 langkah: chat utama → cucu-1 → cucu-2 → cucu-3 → cucu-4 → cucu-5. Dan cabang dapat terbentuk di setiap tingkat. Versi 2.1.172 menghapus aturan bahwa subagent tidak dapat membuat subagent lain. Jika Anda mengejar kecepatan, Anda membutuhkan lebar. Jika urutan eksekusinya ketat, Anda membutuhkan panjang. Kedalaman hanya berguna dalam satu kasus: ketika salah satu tugas Anda memuat **subtugas yang berisik** (15 permintaan web, penelusuran log, membaca belasan berkas), dan Anda tidak ingin semua kebisingan itu membanjiri jendela utama. ## Apa arti “kedalaman 5 tingkat” dalam praktik?
Intisari 5 tingkat adalah jarak vertikal maksimum dari chat utama ke cicit terjauh. Ini batas sisi server; Anda tidak dapat menaikkan, menurunkan, atau menonaktifkannya dengan flag. Sumber resmi juga belum menjelaskan apakah chat utama dihitung sebagai salah satu dari 5 tingkat tersebut.
Ada hal penting yang perlu saya sampaikan dengan jujur. Saya menghabiskan setengah hari membaca dokumentasi dan analisis komunitas untuk mengetahui bahwa Anthropic belum memberikan definisi yang tepat. Inilah yang perlu Anda ketahui. **Ini batas, bukan pengaturan.** Batas ini tertanam di sisi server. Reverse engineering terhadap client v2.1.172 tidak menemukan konstanta `MAX_DEPTH`. Artinya pemeriksaan dilakukan di suatu tempat dalam Anthropic API, bukan secara lokal di mesin Anda. Anda tidak dapat menetapkan `--max-depth 7` untuk membuat pohon lebih dalam. Anda juga tidak dapat menetapkan `--max-depth 2` untuk membuat batas yang lebih rendah dan aman. Satu-satunya kontrol yang Anda miliki adalah allowlist `Agent(agent_type)` di frontmatter—tetapi ini membatasi **jenis** agen anak, bukan kedalamannya. **Anthropic belum mendefinisikan “5” secara tepat.** Ini poin penting kedua: **Anthropic belum mendefinisikan “5” secara tepat.** Sumber resmi tidak menjelaskan apakah depth=5 berarti lima tingkat di bawah root atau lima agen seluruhnya, termasuk root. Untuk saat ini, integrasi pihak ketiga menafsirkannya secara berbeda. ADR-147 di proyek `ruvnet/ruflo` mengasumsikan “5 tingkat anak di bawah root = 6 agen dalam rantai.” Saya menggunakan konvensi yang sama dalam eksperimen: chat utama berada di tingkat 0, anak langsungnya di tingkat 1, dan seterusnya hingga tingkat 5. Namun, konvensi ini tidak tercatat dalam dokumentasi publik. **Batas ini sudah aktif tanpa flag.** Anda tidak perlu mengaktifkan apa pun. Setelah memperbarui Claude Code ke v2.1.172, tambahkan `Agent` ke `tools` milik agen anak, lalu agen itu akan meluncurkan subagent lain. Kuncinya, agen induk harus mengizinkannya (`tools: Agent(...)`). ## Saat ini, Anda mendelegasikan dengan cara apa: lebar, panjang, atau kedalaman?
Intisari Dalam proyek vibe-coding di dunia nyata, saya hampir selalu melihat pendekatan lebar dan sesekali pendekatan panjang. Kedalaman adalah sesuatu yang dilakukan orang secara manual: membuka jendela baru, menyalin prompt, lalu kembali membawa hasilnya. Sebelum 9 Juni, fitur ini belum terpasang. Itulah sebabnya kebanyakan orang bahkan tidak menyadari bahwa mereka belum memilikinya.
Tinjau 5 prompt terakhir Anda. Seberapa sering Anda melakukan hal ini: sebuah tugas dimulai, Claude mulai grep berkas, membuat 10 permintaan web, menumpahkan segunung log ke dalam konteks—lalu 20 menit kemudian Anda sadar jendelanya penuh. Jawaban akhir sudah berjalan dengan anggaran token yang sangat kecil karena 70 persen konteks terpakai oleh tumpukan data perantara. Itulah skenario yang membutuhkan **kedalaman**. Bukan paralelisme, bukan rantai—kedalaman. Chat utama seharusnya mendelegasikan “riset” kepada satu subagent, yang kemudian meluncurkan anak-anaknya sendiri dari dalam untuk pencarian web, pembacaan berkas, dan grep tertentu. Anak-anak itu hanya mengembalikan penilaian yang telah diringkas. Seorang cicit memberi tahu induknya, “ketemu, terkonfirmasi,” atau “tidak ketemu, alasannya X.” Induk menyusunnya menjadi satu ringkasan lalu mengembalikannya kepada Anda. Chat utama tetap bersih. Sebelum 9 Juni, saya menirukan cara ini secara manual. Saya membuka instans Claude Code kedua, menyalin prompt “teliti ini”, menjalankannya, lalu memindahkan hasilnya kembali ke jendela utama secara manual. Dengan v2.1.172, Anda dapat menjelaskannya langsung dalam system prompt orchestrator—Claude akan membangun pohonnya sendiri. ## Dalam 3 skenario apa subagent bersarang benar-benar berguna?
Intisari Tidak untuk setiap tugas. Kedalaman layak digunakan ketika satu delegasi memuat subtugas berisik yang tidak ingin Anda taruh di jendela utama. Saya akan membahas tiga skenario umum yang berulang di kalangan vibe coder: riset mendalam dengan pemeriksaan fakta, analisis repository besar, dan audit dependency end-to-end saat schema atau contract berubah.
### Skenario 1. Riset mendalam dengan pemeriksaan fakta Misalkan Anda mengumpulkan bahan untuk artikel atau proposal penjualan. Pertama, Anda perlu mengambil 5–10 klaim dari sumber publik, lalu memverifikasi masing-masing—menemukan sumber asli, memastikan kutipannya persis, dan menghitung angka sebenarnya. Sebelum v2.1.172, Anda punya dua pilihan. Anda dapat meminta satu subagent melakukan semuanya, yang harus bekerja keras menelusuri 30 permintaan web dan memasukkan semuanya ke dalam konteksnya. Atau membaginya secara manual: satu prompt untuk mengekstrak klaim, lalu menelusuri klaim satu per satu sambil meluncurkan subagent terpisah untuk setiap klaim. Chat utama akan penuh dengan tumpukan daftar perantara. Pada resep di bawah, chat utama mendelegasikan kepada `research-orchestrator` (tingkat 1). Orchestrator mengekstrak klaim sendiri, mengirim masing-masing ke `fact-verifier` (tingkat 2), dan tiap verifier mendelegasikan pencarian terarah ke `web-deep-search` (tingkat 3). Chat utama hanya menerima array klaim terverifikasi beserta sumbernya. Sisanya tetap berada di jendela anak dan tidak pernah masuk ke konteks Anda. ### Skenario 2. Menganalisis repository besar Anda menerima proyek dengan 200 berkas. Anda perlu memahami arsitektur, menemukan modul utama, dan menilai utang teknis. Jalankan `Glob` ditambah selusin pemanggilan `Read` secara manual dan jendela Anda akan penuh dalam 10 menit. Kedalaman menyelesaikannya seperti ini: chat utama meluncurkan subagent “architect”. Architect membuat tiga anak secara internal—yang pertama memeriksa struktur direktori (menjalankan `Glob` lalu merangkum), yang kedua membaca 5 berkas konfigurasi penting, dan yang ketiga melakukan grep untuk pola utama. Masing-masing mengembalikan ringkasan singkat kepada architect. Architect menyusun gambaran keseluruhan dan memberikan laporan akhir sepanjang setengah layar kepada chat utama. Anda mendapatkan peta proyek tanpa membanjiri konteks dengan segunung keluaran `cat` dari semua berkas. ### Skenario 3. Menganalisis dependency end-to-end Anda sedang mengubah schema database, kontrak API, atau berkas konfigurasi bersama. Anda perlu memahami di mana dampaknya akan muncul. Tugas ini paling cepat menghabiskan konteks karena ada banyak dependency dan setiap dependency perlu diperiksa di kode sumber. Dengan kedalaman, chat utama meluncurkan “impact-analyzer” (tingkat 1). Ia meluncurkan satu `dependency-tracer` untuk setiap berkas yang terdampak (tingkat 2). Setiap tracer meluncurkan `consumer-finder` secara internal (tingkat 3), yang melakukan grep pada codebase untuk mencari consumer dependency tersebut. Masing-masing lalu hanya mengembalikan intinya: “tiga tempat ini akan rusak.” Chat utama menyusun tabel “berkas terdampak → dampak” tanpa mengetahui hasil grep-nya. ## Cara menyiapkan subagent bersarang dalam 10 menit
Intisari Tidak perlu flag dan tidak perlu memperbarui konfigurasi. Cukup tambahkan `Agent` ke `tools` agen anak, lalu ia dapat meluncurkan subagent sendiri. Agar pohonnya tidak berubah menjadi kasino, gunakan allowlist `Agent(name1, name2)`. Berikutnya saya akan memberikan template siap pakai untuk orchestrator tiga tingkat yang dapat Anda salin.
**Langkah 1. Pastikan Anda menggunakan v2.1.172 atau lebih baru.** ```bash claude --version ``` Jika versinya lebih rendah, perbarui. Fitur utama rilis ini hanya satu baris di catatan perubahan: “Kini subagent dapat membuat subagent mereka sendiri, hingga kedalaman 5 tingkat” ([teks lengkap](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)). **Langkah 2. Buat agen induk yang dapat meluncurkan anak.** Berkas `.claude/agents/research-orchestrator.md`: ```markdown --- name: research-orchestrator description: Mendelegasikan riset dengan fact-check mendalam tools: Agent(fact-verifier), Read, WebFetch model: opus --- Anda adalah orchestrator riset. Setelah menerima topik: 1. Baca materi yang diberikan atau ambil URL sumber publik yang disediakan. Ekstrak sendiri maksimal 5 klaim konkret. Untuk masing-masing, catat teks klaim, URL atau file sumbernya, dan kutipan pendukung yang tepat. Jika materi sumber belum diberikan, minta terlebih dahulu sebelum mendelegasikan. 2. Panggil fact-verifier untuk setiap klaim — ia akan membuat subagent anaknya sendiri untuk pencarian web dan pemeriksaan silang. 3. fact-verifier hanya akan mengembalikan kesimpulan akhir kepada Anda — jangan masukkan data perantara ke dalam konteks Anda. Laporan akhir hanya berupa array { claim, sources[], confidence }. ``` Baris `tools` hanya memberikan jenis anak `fact-verifier`. Ekstraksi klaim adalah langkah pertama orchestrator sendiri, sehingga tidak perlu file `claim-extractor` yang belum didefinisikan. Daftar izin jenis membatasi anak mana yang dapat dipanggil; itu tidak membatasi berapa kali jenis itu diluncurkan. Batasi resep ini hingga maksimal lima klaim yang diekstrak. **Langkah 3. Buat agen anak yang dapat membuat cucu sendiri.** Berkas `.claude/agents/fact-verifier.md`: ```markdown --- name: fact-verifier description: Memeriksa klaim melalui pencarian web oleh agen anak tools: Agent(web-deep-search), Read model: sonnet --- Anda adalah pemeriksa fakta. Setelah menerima klaim: 1. Rumuskan 2-3 kueri pencarian. 2. Untuk setiap kueri, jalankan web-deep-search — ia akan melakukan WebSearch dan WebFetch sendiri, lalu mengembalikan cuplikan terverifikasi. 3. Satukan menjadi satu verdict: { claim, sources[], confidence }. ``` Lihat bagian pentingnya? `tools` kembali menyebut `Agent(web-deep-search)`. Artinya fact-verifier (tingkat 2 di pohon kita) dapat meluncurkan subagent lain sendiri (tingkat 3). Sebelumnya, baris ini tidak berpengaruh—dokumentasi masih memuat kalimat:
Subagent tidak dapat membuat subagent lain, jadi Agent(agent_type) tidak berfungsi dalam definisi subagent.
— Dokumentasi Claude Code, https://code.claude.com/docs/en/sub-agents
Dengan v2.1.172, baris itu sudah usang. Sintaksnya tetap sama, tetapi sekarang berfungsi di tingkat mana pun dalam pohon. **Langkah 4. Buat agen cicit.** Berkas `.claude/agents/web-deep-search.md`: ```markdown --- name: web-deep-search description: Melakukan pencarian web dan mengembalikan cuplikan tools: WebSearch, WebFetch model: haiku --- Anda menerima kueri pencarian. Lakukan WebSearch, pilih 3 URL yang paling relevan, lalu gunakan WebFetch untuk mengambil bukti yang secara verbatim mendukung klaim. Kembalikan array { url, snippet, supports_claim: yes|no }. ``` Agen cicit tidak memiliki `Agent` di `tools`, jadi ia tidak membuat agen lebih jauh di pohon. **Langkah 5. Jalankan orchestrator.** ```bash claude --agent research-orchestrator ``` Lalu berikan teks sumber atau URL sumber publik di chat: “Ekstrak dan verifikasi maksimal 5 klaim konkret dari sumber-sumber ini; kembalikan klaim, sumber, dan keyakinan.” Dengan `--agent research-orchestrator`, sesi itu sendiri adalah orchestrator; anak verifier dan pencariannya menambahkan dua tingkat delegasi di bawahnya. Jika sesi utama biasa mendelegasikan kepada orchestrator ini, terdapat tiga tingkat delegasi di bawah sesi utama tersebut. ## 5 anti-pola apa yang membuang token dan merusak observabilitas?
Intisari Kedalaman itu mahal. Setiap tingkat tambahan melipatgandakan token, dan pelipatgandaan itu terus menumpuk. Berikut lima skenario saat nesting merugikan. Jangan lakukan ini—atau anggaran harian Anda akan habis dalam satu jam dan Anda akan kehilangan jejak kesalahan empat lantai di dalam pohon.
**Anti-pola 1. Tugasnya muat dalam satu jendela.** Jika satu subagent dapat menanganinya tanpa kebisingan, jangan tambahkan tingkat: nesting hanya menambah biaya dan latensi tanpa alasan. **Anti-pola 2. Anda mengejar kecepatan, bukan isolasi.** Jika Anda menginginkan kecepatan, gunakan **paralelisme**, bukan kedalaman. Luncurkan 5 subagent berdampingan pada tingkat yang sama daripada membangun rantai. Kedalaman ada untuk memindahkan pekerjaan persiapan yang berisik ke jendela anak, bukan untuk mempercepat pekerjaan. **Anti-pola 3. Pekerjaannya memang sederhana dan dangkal.** “Temukan berkas ini dan tunjukkan kepada saya” adalah **permintaan dua langkah**; tidak membutuhkan hierarki tiga tingkat. Nesting layak digunakan ketika tugas memuat subtugas yang berisik. Jika tidak ada kebisingan, jangan tambahkan subagent. **Anti-pola 4. Prompt di tingkat pertama samar-samar.** Inilah skenario paling berbahaya. Jika Anda memberikan prompt samar kepada orchestrator tingkat 1, kesamarannya akan berlipat ganda. Satu prompt samar tingkat 1 menjadi 4 prompt samar di tingkat 2 dan 16 di tingkat 3. Saat para cucu mulai bekerja, mereka bahkan tidak tahu apa yang harus dicari. **Anti-pola 5. Biaya tumbuh secara geometris.** Argumen ekonomi utamanya: nesting melipatgandakan penggunaan token, dan penggandaan itu terus menumpuk seiring kedalaman. Perhitungan kasar: rantai kedalaman 3 dengan fan-out 3 pada setiap tingkat berarti 27 subagent. Itu setidaknya membutuhkan token 27 kali lebih banyak daripada permintaan sederhana. Dengan paket Pro Claude, perhitungan ini akan menghabiskan batas harian dalam beberapa jam. Jika Anda memakai paket Max, jatah seminggu akan habis dalam sehari. **Anti-pola bonus (pengalaman saya): “50 agen melakukan pekerjaan sia-sia.”** Saat melihat proyek orang lain, saya sering menjumpai hal ini: “Saya punya 50 agen yang bekerja.” Saya bertanya, apa yang mereka kerjakan? Ternyata 50 agen itu **melakukan pekerjaan sia-sia**. Mereka menghasilkan tumpukan keluaran tak perlu, banyak ringkasan mentah, duplikasi, dan segunung log. Masing-masing mengerjakan sesuatu yang “secara umum berguna”, dan hasilnya adalah konteks yang tenggelam serta tagihan token seperti milik perusahaan kecil. Kedalaman 5 tidak menyelesaikan masalah ini—justru **memperburuknya**. Jika di tingkat 1 saja tidak jelas siapa mengerjakan apa, kedalaman 5 berarti lima tingkat kebingungan. Sebelum meluncurkan subagent apa pun, uji dengan menjawab 4 pertanyaan dalam setengah menit: - Apa tepatnya yang dikerjakannya (dalam satu kalimat)? - Berkas mana yang disentuhnya? - Apa yang dikembalikannya kepada induk? - Siapa yang memeriksanya? Jika Anda tidak dapat menjawab dalam 30 detik, subagent ini seharusnya tidak ada. Saya menjelaskan aturan ini secara terpisah dalam panduan [tentang subagent paralel](https://ailoot.ai/blog/id/claude-code-parallel-worktree-agents/). ## Mengapa nesting tanpa context engineering berarti 5 tingkat halusinasi?
Intisari Jebakan utama delegasi mendalam adalah konteks tugas yang tidak lengkap. Anak tidak otomatis menerima seluruh percakapan induk atau setiap file yang dibacanya. Subagent khusus biasanya memuat instruksi CLAUDE.md yang berlaku kecuali dikonfigurasi untuk melewatkannya; itu tidak otomatis memuat semua file bisnis yang dirujuk. Berikan materi sumber, jalur, dan kontrak hasil yang tepat pada setiap serah terima. Jika proyek Anda tidak memiliki struktur konteks yang kuat, semakin dalam pohonnya, semakin jauh setiap cucu melayang ke dalam khayalan. Anda mendapatkan 5 lantai halusinasi, satu di setiap tingkat.
Di sinilah orang sering bertanya: “Saya memperbarui Claude Code, menambahkan Agent ke tools, pohonnya terbentuk—tetapi jawaban akhirnya masih meleset. Mengapa?” Jawabannya sederhana. Setiap subagent di Claude Code memulai **dari awal**. Menurut dokumentasi resmi:
Setiap subagent memulai dengan jendela baru yang terisolasi. Ia tidak dapat melihat riwayat percakapan, skills yang sudah Anda panggil, atau berkas yang sudah dibaca Claude.
— Dokumentasi Claude Code, https://code.claude.com/docs/en/sub-agents
Di tingkat 1, ini masih dapat dikelola: orchestrator meneruskan deskripsi tugas singkat kepada anaknya. Namun di tingkat 3, cucu menerima pesan delegasi dari induknya, yang juga hanya memiliki pesan delegasi. Masing-masing hanya meneruskan sedikit informasi. Pada tingkat 5, Anda memiliki subagent yang jendelanya hanya berisi frasa “periksa klaim X” dan tidak ada yang lain. Ia tidak tahu sedang mengerjakan proyek apa, tugas apa yang diselesaikan, atau apa yang harus menjadi fokusnya. Tanpa [CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/), cucu tingkat lima seperti karyawan yang datang ke kantor untuk pertama kalinya seumur hidup tanpa orientasi. Ia akan mengerjakan sesuatu karena diberi tugas. Namun, hasilnya tidak akan sesuai dengan kebutuhan proyek. ## Apa lagi yang berubah di v2.1.172 selain nesting?
Intisari Rilis ini berfokus pada subagent. Selain fitur utama, ada 4 perbaikan untuk infrastruktur delegasi. Salah satunya memperbaiki bug yang hanya dapat terjadi dengan nesting.
Buka catatan rilis lengkap v2.1.172 dan Anda akan melihat seluruh rilis ini membahas subagent. **Perbaikan 1.** Subagent latar belakang tidak lagi tetap “tersangkut” sebagai aktif di panel agents setelah subagent bersarang yang diluncurkannya dihentikan. Bug ini hanya dapat terjadi saat nesting. **Perbaikan 2.** Pembatasan `availableModels` kini juga berlaku bagi subagent. Sebelumnya, jika Anda membatasi model yang dapat digunakan tim (misalnya melarang opus untuk menghemat biaya), subagent dapat melewati aturan itu dengan override di konfigurasinya sendiri. Dengan v2.1.172, aturan berlaku di mana-mana. **Perbaikan 3.** Tombol panah atas di riwayat prompt kini menampilkan prompt dari tab **saat ini** milik subagent, bukan milik agen utama. Ini penyempurnaan observabilitas. **Perbaikan 4.** Penggunaan CPU saat menganggur berkurang: indikator `/goal` tidak lagi menggambar ulang terminal pada 5 Hz saat menganggur, dan UI lebih jarang menggambar ulang saat subagent paralel bekerja. Saya ingin menunjukkan bahwa keempat perbaikan ini berkaitan dengan subagent. Artinya Anthropic merilis seluruh tumpukan infrastruktur nesting, bukan hanya satu baris di catatan rilis. Nesting sudah digunakan di internal Anthropic selama beberapa waktu sebelum diumumkan. ## Daftar periksa: kapan nesting membantu dan kapan merugikan
Intisari Sebelum setiap peluncuran subagent baru, periksa tugasnya dengan 6 pertanyaan. Jika setidaknya 3 jawabannya “ya, gunakan kedalaman”, gunakanlah. Jika kurang, tetap gunakan paralelisme atau satu subagent. Ini akan menghemat token, kesabaran, dan beberapa jam yang mungkin Anda habiskan untuk mencari tahu apa yang dikerjakan oleh rantai 27 peluncuran bersarang.
Gunakan nesting jika: - Tugas memuat subtugas yang melibatkan banyak permintaan web, grep, atau pembacaan berkas. - Tidak masalah jika subtugas itu gagal (jika cucu mengembalikan “tidak menemukan apa pun”, orchestrator dapat melanjutkan). - Anda **tidak membutuhkan** hasil perantara di jendela utama. - Anda memiliki `CLAUDE.md` dan konteks proyek yang telah disusun untuk dijadikan acuan oleh subagent. - Anda dapat menjelaskan dengan gamblang apa yang dikembalikan setiap tingkat (masukan, keluaran, format). - Anda menggunakan paket Max atau memiliki cadangan untuk token ×27. Jangan gunakan nesting jika: - Satu subagent dapat menyelesaikan tugas tanpa kebisingan. - Anda membutuhkan hasil perantara di jendela utama (berarti Anda menginginkan paralelisme). - Proyek tidak memiliki CLAUDE.md atau hanya memiliki sedikit konteks bisnis. - Prompt tingkat 1 samar-samar (kesamaran akan berlipat ganda secara eksponensial di dalam pohon). - Anda membutuhkan kecepatan—paralelisme lebih cepat daripada kedalaman untuk hasil yang sebanding. - Anda menggunakan paket Pro dan bekerja sepanjang hari—batasnya akan habis dalam beberapa jam.
### Sumber - [Rilis Claude Code v2.1.172 - GitHub Releases](https://github.com/anthropics/claude-code/releases/tag/v2.1.172) - [Membuat subagent kustom - Dokumentasi Claude Code](https://code.claude.com/docs/en/sub-agents)
Materi lainnya tersedia di [Ailoot](https://ailoot.ai/). ## Pertanyaan tentang Cara mendelegasikan tugas besar di Claude Code menggunakan subagent bersarang ### Apakah perlu membuat claim-extractor untuk resep yang disalin? Tidak. research-orchestrator yang diperbaiki mengekstrak sendiri maksimal lima klaim dari materi yang diberikan. Buat tiga file yang ditampilkan: research-orchestrator, fact-verifier, dan web-deep-search; lalu berikan teks sumber atau URL. ### Apakah hanya mengizinkan fact-verifier membatasi jumlah peluncuran anak? Tidak. Daftar izin jenis agen membatasi jenis yang dapat dipanggil, bukan jumlah pemanggilannya. Resep ini secara terpisah membatasi ekstraksi awal menjadi lima klaim; pantau pemanggilan dan pemakaian token sebenarnya. ## Ailoot · Perusahaan dan portofolio proyeknya Ailoot bertumpu pada pengalaman operasional yang teruji, basis pelanggan yang besar, layanan yang stabil, dan pemantauan KPI berkelanjutan. Perusahaan dan portofolio proyeknya: jutaan pelanggan; penjualan miliaran setiap bulan. Ailoot memanfaatkan pengalaman operasional ini untuk akses API ke fitur AI dalam produk pelanggan, agen, aplikasi, dan otomatisasi.