Claude Code Dynamic Workflows: Orkestrasi 1.000 Agent

Pertama kali saya meminta Claude mengaudit setiap route handler di sebuah proyek untuk auth check yang hilang, ia melakukan apa yang dilakukan percakapan: baca satu file, laporkan, baca berikutnya, laporkan. Sampai file keempat puluh, temuan awal sudah tersapu compaction dan ringkasan di akhir hanyalah ringkasan dari delapan file terakhir. Orkestrasinya berebut context window dengan pekerjaannya sendiri.

Workflow menghapus perebutan itu dengan memindahkan rencananya ke dalam kode. Tulisan ini membahas kapan workflow mengalahkan tiga cara lain untuk memparalelkan pekerjaan, API script yang akan benar-benar Anda baca, keputusan pipeline lawan barrier yang menentukan wall-clock time, batas runtime yang membentuk apa yang bisa ditulis, dan aturan resume yang membuat menghentikan run di tengah fan-out jauh lebih mahal daripada kelihatannya.

Empat cara memparalelkan, dan siapa yang memegang rencananya

Subagent, skill, agent teams, dan workflow sama-sama bisa menjalankan tugas multi-langkah. Yang membedakannya adalah siapa yang memutuskan apa yang jalan berikutnya, dan di mana hasil antaranya mendarat. Pada tiga yang pertama, Claude adalah orkestratornya: ia memutuskan giliran demi giliran apa yang dipanggil, dan setiap hasil kembali ke sebuah context window. Script workflow memegang loop, percabangan, dan hasil antaranya sendiri, sehingga context Claude hanya berisi jawaban akhirnya.

Perbedaan yang benar-benar menentukan mana yang Anda butuhkan:

Menjalankannya, dan di mana keyword-nya tidak berlaku

Cara tercepat melihat bentuknya adalah satu workflow bawaan. Menjalankan deep research menyebar pencarian web ke beberapa sudut, memeriksa silang sumber yang ditemukan, memungut suara untuk tiap klaim, dan mengembalikan laporan bersitasi dengan klaim yang gagal cross-check sudah tersaring. Klaim yang tidak bisa diverifikasi — misalnya karena kena rate limit — dicantumkan sebagai belum terverifikasi, bukan dihitung sebagai terbantah. Perbedaan itulah yang paling sering keliru di perkakas riset lain.

# Run the one bundled workflow to see the shape first.
/deep-research What changed in the Node permission model in v22?

# Ask for a workflow on your own task. The keyword only works in
# a prompt you type yourself — not from -p, not from a scheduled
# task, and not from a webhook or PR comment relayed into the run.
ultracode: audit every endpoint under src/routes/ for missing auth

# Or let Claude decide for every substantive task this session.
# ultracode = xhigh effort + automatic workflow orchestration.
/effort ultracode

# Watch it. The progress view shows per-phase agent counts,
# token totals and elapsed time.
/workflows
#   f  filter agents in the phase by status
#   p  pause or resume the run
#   x  stop the selected agent, or the whole run
#   r  restart the selected running agent
#   s  save this run's script as a reusable /command

Keyword ultracode hanya berlaku sebagai opt-in pada prompt yang Anda ketik sendiri, di prompt interaktif, di panel IDE, atau di klien Remote Control. Ia sengaja tidak memulai workflow dari prompt yang dikirim lewat flag -p, dari scheduled task, atau dari payload webhook maupun komentar pull request yang diteruskan ke percakapan. Sebelum v2.1.210 keyword itu memang menyala dari jalur-jalur tersebut, yang artinya satu komentar di PR bisa memicu run seratus agent.

API script-nya lebih kecil daripada dugaan Anda

Setiap script dibuka dengan blok meta yang harus berupa literal murni — tanpa variabel, tanpa interpolasi template, tanpa pemanggilan fungsi — diikuti JavaScript biasa dengan top-level await. Badannya punya lima hook: agent untuk memunculkan satu subagent, parallel dan pipeline untuk fan-out, phase untuk mengelompokkan progres, dan log untuk bercerita. Hampir itu saja isinya.

// .claude/workflows/audit-routes.js — plain JavaScript with
// top-level await. No imports: a script containing import()
// fails before the run even starts.
export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
  phases: [
    { title: 'Discover' },
    { title: 'Audit' },
    { title: 'Verify' },
  ],
}

phase('Discover')
const found = await agent('List every .ts file under src/routes/.', {
  schema: {
    type: 'object',
    required: ['files'],
    properties: { files: { type: 'array', items: { type: 'string' } } },
  },
})

// pipeline() runs each item through EVERY stage independently.
// File A can be in Verify while file B is still in Audit.
const audits = await pipeline(
  found.files,
  file => agent('Audit ' + file + ' for missing auth checks.', {
    label: file, phase: 'Audit', schema: FINDINGS,
  }),
  review => agent('Adversarially refute: ' + review.claim, {
    phase: 'Verify', schema: VERDICT,
  }),
)

// An agent you stop, or one that dies on a terminal API error,
// resolves to null — pipeline keeps the null in the array.
return audits.filter(Boolean)

pipeline adalah default; barrier harus membuktikan haknya

Ini keputusan yang menentukan wall-clock time, dan paling sering salah pada script yang ditulis tangan. Panggilan parallel adalah barrier: ia menunggu semua tugas selesai sebelum mengembalikan apa pun. Pipeline menjalankan tiap item melewati seluruh tahapnya secara independen, jadi item A bisa berada di tahap tiga sementara item B masih di tahap satu. Wall-clock time sebuah pipeline adalah rantai satu item terlambat, bukan jumlah item terlambat di tiap tahap.

Uji yang saya pakai: kalau saya menulis barrier, mengumpulkan hasilnya, lalu langsung map atau flatten atau filter tanpa perbandingan antaritem, barrier itu tidak dibutuhkan dan transformasinya seharusnya berada di dalam satu tahap pipeline. Barrier benar-benar tepat hanya pada tiga kasus:

• Deduplikasi atau penggabungan lintas seluruh hasil sebelum tahap hilir yang mahal.
• Keluar lebih awal berdasarkan total — melewati verifikasi sama sekali ketika tahap pencari mengembalikan nol temuan.
• Sebuah tahap yang prompt-nya memang merujuk temuan lain untuk dibandingkan.

Batas yang membentuk apa yang bisa Anda tulis

Runtime-nya sengaja dibatasi, dan tiap batasan mengubah cara Anda menyusun script, bukan sekadar membatasinya:

• Maksimal 16 agent bersamaan, lebih sedikit jika Claude Code melihat CPU lebih sedikit — termasuk di dalam container yang dibatasi CPU. Mengirim 200 item tetap selesai; hanya sekitar selusin yang berjalan pada satu saat.
• Total 1.000 agent per run, sebagai pengaman loop liar, bukan batas desain.
• Tidak ada pemuatan modul. Script yang memuat dynamic import gagal sebelum run dimulai, jadi apa pun yang butuh library harus masuk ke dalam tugas sebuah agent.
• Tidak ada akses filesystem atau shell dari script itu sendiri. Agent yang membaca, menulis, dan menjalankan perintah; script hanya mengoordinasi mereka.

Resume mengikuti urutan mulai, dan itu mahal

Anda bisa menghentikan sebuah run lalu melanjutkannya, dan agent yang sudah selesai biasanya mengembalikan hasil dari cache. Dua aturan menentukan apa yang selamat, dan aturan kedua cukup berlawanan dengan intuisi sampai layak digambarkan.

# Why stopping mid fan-out is expensive.
#
# A script starts four agents in this order: A, B, C, D.
# You stop the run while B is still going.
#
# On resume:
#   A  -> returns from cache        (finished, started before B)
#   B  -> runs again                (never finished)
#   C  -> runs again                (started AFTER B)
#   D  -> runs again                (started AFTER B)
#
# Replay follows START ORDER, and cached results stop at the
# first agent that did not finish. C and D completed and are
# still discarded. Many small agents therefore preserve far
# more progress than one long one.

Ini argumen terkuat untuk menyebar pekerjaan ke banyak agent kecil ketimbang beberapa agent panjang: workflow berisi empat puluh agent pendek hanya kehilangan segelintir hasil saat dihentikan, sedangkan workflow berisi empat agent panjang bisa kehilangan hampir semuanya. Resume juga hanya bekerja dalam sesi Claude Code yang sama — keluar dari CLI saat workflow berjalan dan sesi berikutnya memulainya dari nol.

Menjaga tagihan tetap sebanding dengan tugasnya

Workflow memunculkan banyak agent, jadi satu run bisa memakai token jauh lebih banyak daripada mengerjakan tugas yang sama lewat percakapan. Panduan ukuran di config memberi tahu Claude berapa agent yang sebaiknya dituju saat menulis script: small di bawah lima, medium di bawah lima belas, large di bawah lima puluh, dan unrestricted membiarkan Claude menyesuaikan dengan tugasnya. Defaultnya medium. Ini saran yang dikirim ke model, bukan batas keras, jadi prompt yang memang menuntut skala berbeda tetap menimpanya.

Aturan yang akhirnya saya pakai: workflow layak dipakai ketika langkah yang sama harus dijalankan pada banyak item, atau ketika tugasnya lebih besar dari yang muat di satu agent. Di bawah garis itu, percakapan lebih murah dan lebih mudah dikemudikan. Di atasnya, kemenangan sesungguhnya bukan pada jumlah agent-nya — melainkan pada orkestrasi yang berubah menjadi file yang bisa Anda baca, bandingkan dengan run sebelumnya, edit, lalu jalankan lagi di branch enam minggu kemudian dan tetap mendapat bentuk jawaban yang sama.