Dispatch Rules Multi-Agent via delegate_task di SOUL.md

Mengandalkan single agent (sequential) memakan waktu lama dan rentan bottleneck. Dengan memanfaatkan delegate_task, kita dapat mengaktifkan sistem operasi paralel yang heavy untuk multi-domain di SOUL.md secara simultan.

Single-Agent vs Parallel Processing

Dalam sistem agent yang paling standar, eksekusi berjalan secara linear (sequential). Artinya, agent baru bisa melangkah ke task B setelah task A benar-benar selesai. Namun, ini memicu isu bottleneck saat agent harus menghadapi payload berat seperti riset ekstensif web dan eksekusi skrip komputasi secara bersamaan.

Dengan delegate_task, masalah ini bisa diselesaikan melalui Parallel Processing. Lo bisa mendelegasikan perintah (A, B, C) bersamaan menggunakan subagents. Di konfigurasi Hermes, by default, child agents ini dibatasi maksimal berjalan 3 concurrency. Master agent (misal Kala) cuma bertugas memecah task, melempar instruksi, lalu diam dan menunggu subagent balik membawa ringkasan.

Konfigurasi Dispatch Rules di SOUL.md

Sistem ini nggak cuma butuh tools, tapi butuh aturan kapan Kala harus nge-handle sendiri atau manggil subagent. Dispatch rules ini didefinisikan secara eksplisit di SOUL.md.

Langkah utamanya:

• Mendefinisikan Domain Registry: Lo harus pastikan agent-agent pembantu ini (contoh: Wisanggeni untuk Dev, Dananjaya untuk QA, Antareja untuk Research) sudah masuk dalam mapping Kala.
• Rules Eksekusi: Atur kapan Kala jalanin sequential (goal mode) dan kapan nembak ke tasks mode untuk parallel processing (misalnya ketika butuh input dari berbagai domain secara serentak).

Implementasi delegate_task di Dunia Nyata

Kebayang ada project dimana lo butuh data analytics dari sebuah platform, sekaligus konten draft untuk review. Tanpa multi-agent, ini berurutan. Dengan parallel processing, Kala bisa mengirimkan sub-task analytics ke Citrasena sambil di saat yang bersamaan Srikandi disuruh bikin content creation.

Proses memecah job desk juga sangat terfokus. Citrasena cuma diaktifin toolset terminal untuk running script analytic, sementara Srikandi dikasih web dan browser aja. Keduanya jalan terisolasi.

Best Practices & Pitfalls

Jangan sampai subagent malah bikin pusing, ingat beberapa hal fundamental ini:

• No Memory Access: Subagents nggak tahu sejarah chat lo sebelumnya. Harus super eksplisit ngasih instruksi di field context (sebut path spesifik, rules spesifik, dan error constraints).
• Orchestrator Limits: Secara default max_spawn_depth=1 untuk user, yang berarti subagent lo cuma sebagai leaf (fokus eksekusi, gak bisa mendelegasikan tugas ke anak lagi).
• Trust but Verify: Child agent itu ngelaporin apa yang mereka klaim (self-report). Kalau agent bilang "File success written", jangan langsung telan mentah-mentah. Kala tetep wajib lakuin `cat`, `ls`, atau cek status file secara manual sebelum ngasih tau hasil akhir.

Contoh Payload delegate_task

{
  "tasks": [
    {
      "goal": "Tarik data log seminggu terakhir pakai curl, parsing, sum up total error",
      "context": "File path target di /var/log/nginx/error.log. Ekstrak cuma angka fatal.",
      "toolsets": ["terminal"],
      "role": "leaf"
    },
    {
      "goal": "Riset web soal 3 kompetitor direct dari API gateway yg kita pakai",
      "context": "Simpan poin kelemahan aja.",
      "toolsets": ["web"],
      "role": "leaf"
    }
  ]
}