Fase 3 · AI Agents

Multi-agent & orchestration

Sama seperti backend yang tumbuh dari satu monolith menjadi beberapa service dengan tanggung jawab jelas, agent yang menangani tugas kompleks sering lebih andal saat dipecah jadi beberapa agent khusus yang berkoordinasi.

Sumber asli anthropic.com Artikel Rangkuman ~8 menit baca

Intisari

Satu agent dengan terlalu banyak tool & tanggung jawab cenderung 'bingung' — salah pilih tool, kehilangan fokus di tugas panjang. Ini masalah yang sama seperti class yang melanggar single responsibility principle.
Pola orchestrator-worker: satu agent 'pemimpin' memecah tugas besar jadi sub-tugas, mendelegasikan ke agent 'pekerja' yang lebih sempit fokusnya, lalu menggabungkan hasilnya.
Sub-agent bisa berjalan paralel untuk sub-tugas yang independen — mempercepat penyelesaian, mirip fan-out ke beberapa service sekaligus.
Biaya & kompleksitas naik signifikan dengan multi-agent — token terpakai berkali lipat (tiap agent punya context window sendiri) dan debugging jadi lebih sulit (banyak 'pelaku' yang berinteraksi).
Jangan mulai dari multi-agent. Mulai dari satu agent (atau bahkan cukup workflow biasa), dan naik ke multi-agent hanya kalau ada bukti konkret satu agent tidak cukup.

Kenapa satu agent bisa 'kehilangan fokus'

Semakin banyak tool dan tanggung jawab yang diberikan ke satu agent, semakin besar context window-nya terisi instruksi & riwayat yang tidak selalu relevan untuk keputusan saat itu — dan semakin besar peluang model salah pilih tool atau "lupa" tujuan awal di tengah tugas panjang. Ini paralel langsung dengan prinsip software engineering: class yang mengerjakan terlalu banyak hal susah dipelihara, agent yang mengerjakan terlalu banyak hal susah diandalkan.

Pola orchestrator–worker

Pola paling umum: satu agent orchestrator (pemimpin) menerima tugas besar, memecahnya jadi beberapa sub-tugas yang lebih sempit, mendelegasikan tiap sub-tugas ke agent worker yang fokus sempit dan punya tool terbatas sesuai tugasnya, lalu mengumpulkan & menyatukan hasilnya.

Tugas: "Riset kompetitor kami di tiga kota berbeda dan buat rangkuman perbandingan"

Orchestrator
  ├── Worker A: riset kompetitor di Jakarta  (tool: web search, terbatas ke topik ini)
  ├── Worker B: riset kompetitor di Surabaya (tool: web search, terbatas ke topik ini)
  ├── Worker C: riset kompetitor di Medan    (tool: web search, terbatas ke topik ini)
  └── Orchestrator menggabungkan 3 hasil jadi satu rangkuman perbandingan

def worker_riset(kota: str) -> str:
    # agent sempit: satu tool, satu tujuan jelas
    return jalankan_agent(f"Riset kompetitor toko online di {kota}", tools=[tool_web_search], tool_impl={...})

def orchestrator_riset(kota_list: list[str]) -> str:
    hasil_per_kota = {kota: worker_riset(kota) for kota in kota_list}  # bisa dijalankan paralel

    return client.messages.create(
        model="claude-sonnet-4-5", max_tokens=1024,
        messages=[{"role": "user", "content": f"Rangkum perbandingan dari hasil riset ini: {hasil_per_kota}"}],
    ).content[0].text

Sub-tugas yang independen bisa dijalankan paralel — tiga worker riset kota berbeda di atas tidak saling bergantung, jadi bisa dipanggil bersamaan (mis. lewat asyncio.gather atau thread pool) alih-alih berurutan. Ini mempercepat waktu total secara signifikan untuk tugas yang bisa dipecah begini — pola yang mirip errgroup/fan-out di backend biasa.

Harga yang harus dibayar

Trade-off	Penjelasan
Token jauh lebih banyak	Tiap sub-agent punya context window & riwayat sendiri — total token terpakai bisa berkali lipat dari satu agent tunggal
Debugging lebih sulit	Kegagalan bisa berasal dari orchestrator, salah satu worker, atau cara hasil digabungkan — butuh tracing per-agent (Fase 7)
Koordinasi tambahan	Orchestrator perlu logika menangani worker yang gagal sebagian, timeout per-worker, dsb.

Jangan mulai dari sini. Anthropic sendiri (di sumber materi ini, tentang sistem riset multi-agent mereka) menekankan bahwa multi-agent hanya masuk akal untuk tugas yang benar-benar bisa dipecah jadi sub-tugas paralel independen dengan nilai yang sepadan dengan biaya token ekstra. Untuk sebagian besar kasus, satu agent yang dirancang baik (tool sedikit tapi jelas, batas langkah wajar) sudah cukup — mulai dari sana, dan naikkan kompleksitas hanya saat ada bukti konkret dibutuhkan.

Latihan: ambil satu tugas yang secara alami bisa dipecah jadi 2-3 sub-tugas independen (mis. "bandingkan harga produk X di tiga kategori berbeda"). Implementasikan versi satu-agent (semua tool digabung) dan versi orchestrator-worker, lalu bandingkan: waktu total eksekusi, jumlah token terpakai, dan seberapa mudah kamu melacak di mana kesalahan terjadi kalau hasilnya salah.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.