Belajar Hermes AI Agent - Multi-agent Coordination

#Pendahuluan

Di episode 16 kalian memperluas kemampuan agent dengan custom actions, tool domain-spesifik, dan plugin yang dikemas sebagai modul. Sekarang bayangkan kalian punya bukan satu, tapi beberapa agent dengan keahlian berbeda: satu jago riset, satu jago analisis data, satu lagi jago komunikasi. Pertanyaannya: bagaimana mereka bekerja sama tanpa saling menjegal?

Roadmap episode ini: mengenali kapan multi-agent justru tepat, memahami pola komunikasi antar agent, membangun orkestrator yang mendelegasikan subtask dan menyatukan hasil, lalu menyusun strategi konsistensi dan arbitrasi ketika hasil para agent bertabrakan.

#Kapan Multi-agent Justru Tepat

Satu agent punya batas: context window terbatas, tool set yang membengkak, dan semua keputusan lewat satu otak. Ketika tugas mulai membutuhkan banyak pengetahuan sekaligus — bandingkan harga dari tiga sumber, analisis log besar, lalu tulis ringkasannya — satu agent akan lambat dan mudah "tersesat" di tengah konteks yang membludak.

Multi-agent membagi beban: setiap worker punya context kecil dan tool yang fokus, orkestrator hanya mengatur lalu lintas. Tapi ini bukan solusi gratis. Setiap agent adalah biaya token, dan koordinasi menambah latensi. Aturan praktisnya: mulai dengan satu agent, pindah ke multi-agent hanya ketika ada hambatan yang jelas — context window habis, satu jenis tool terlalu banyak, atau satu agent kewalahan menangani banyak tugas paralel.

#Pola Komunikasi Antar Agent

Ada tiga pola komunikasi yang umum dipakai, dan masing-masing cocok untuk situasi berbeda:

• Direct channel — agent A mengirim pesan langsung ke agent B. Cocok untuk delegasi satu-ke-satu yang sudah jelas arahnya.
• Message bus — agent memublikasikan peristiwa ke topik, siapa pun yang tertarik boleh subscribe. Cocok untuk fan-out: satu peristiwa dibaca banyak agent.
• Shared memory / blackboard — beberapa agent menulis dan membaca state yang sama. Kuat tapi berisiko, karena masalah konsistensi datang di sini.

Bus Hermes dikonfigurasi lewat deklarasi channel:

channels:
  orders:
    type: topic
    durability: 24h
  support:
    type: direct

import { channel } from "@hermes/network";
 
await channel("orders").publish({
  event: "order_created",
  orderId: "ORD-2026-0142",
  amount: 520000,
});

Gunakan direct untuk hasil yang harus kembali ke pengirim, dan topic untuk peristiwa yang relevan bagi banyak agent sekaligus. Shared memory paling efisien untuk state bersama, tapi simpan ia untuk bagian paling akhir episode ini — konsistensinya butuh perhatian khusus.

#Delegasi Subtask: Orkestrator dan Worker

Pola paling banyak dipakai adalah orchestrator-worker: satu agent orkestrator memecah tugas besar menjadi subtask, mendelegasikan tiap subtask ke worker yang kompeten, menunggu hasil, lalu menyatukannya. Orkestrator tidak perlu tahu detail pengerjaan — ia hanya memastikan semuanya berjalan dan hasilnya utuh.

import { HermesAgent } from "@hermes/sdk";
 
const orchestrator = new HermesAgent({ profile: "./profiles/orchestrator.ts" });
 
async function runBatch(task, subtasks) {
  const results = await Promise.all(
    subtasks.map((sub) =>
      orchestrator.spawn({
        agent: sub.agent,
        task: sub.task,
        replyTo: "orchestrator",
      }),
    ),
  );
  return orchestrator.merge(results);
}

Alurnya: orkestrator memecah task menjadi daftar subtasks, setiap worker di-spawn dengan task dan replyTo sebagai alamat balasan, hasil dikumpulkan paralel, lalu merge menyusunnya menjadi satu jawaban koheren. Karena tiap worker punya context sendiri, model tidak kewalahan oleh konteks gabungan. Di CLI, spawn manual tersedia lewat hermes agent spawn untuk menguji satu worker sebelum dirangkai ke pipeline.

#Menjaga Konsistensi di Banyak Agent

Begitu beberapa agent menyentuh data yang sama, konsistensi menjadi masalah. Dua worker yang mengedit record yang sama secara paralel bisa saling menimpa. Tiga strategi yang paling praktis:

• Single writer per resource — untuk setiap resource (misalnya satu order), hanya satu worker yang boleh menulis. Orkestrator menetapkan kepemilikan di awal.
• Idempotent tool calls — buat tool yang aman dipanggil berkali-kali dengan hasil yang sama, lengkap dengan idempotency key, sehingga retry atau duplikasi tidak menimbulkan efek ganda.
• Versioned shared state — kalau blackboard dipakai, setiap tulis membawa versi; worker yang membaca versi lama tahu datanya sudah berubah dan harus mengambil ulang.

export async function writeOrder(store, orderId, patch) {
  const current = await store.get(orderId);
  if (patch.baseVersion !== current.version) {
    throw new Error("stale write: versi sudah berubah");
  }
  return store.set(orderId, {
    ...current,
    ...patch.data,
    version: current.version + 1,
  });
}

Pola ini membuat write yang "basah" ditolak sejak awal alih-alih menimpa data pekerja worker lain secara diam-diam. Kalau konflik tetap terjadi, ia harus ditangani eksplisit — dan di sinilah arbitrasi berperan.

#Arbitrasi Saat Hasil Bentrok

Ketika beberapa agent memberikan jawaban berbeda untuk pertanyaan yang sama, kalian butuh aturan untuk memilih. Arbitrasi adalah mekanisme itu. Strategi paling umum: pilih yang confidence-nya tertinggi, atau minta mayoritas — dan jika tidak ada yang cukup yakin, naikkan ke manusia alih-alih memaksa.

export function arbitrate(results) {
  const ranked = [...results].sort((a, b) => b.confidence - a.confidence);
  const best = ranked[0];
 
  if (best.confidence < 0.6) {
    return { winner: null, escalate: true };
  }
  return { winner: best, escalate: false };
}

Aturan arbitrasi paling baik dideklarasikan, bukan dikode keras: konfigurasi berisi strategi (confidence, majority, priority), ambang yang memicu eskalasi, dan ke mana hasil naik jika tidak ada pemenang. Konsistensi yang terjaga sejak penulisan state, ditambah arbitrasi yang jelas di titik bentrok, adalah dua sisi yang membuat tim agent bekerja seperti satu sistem — bukan lima aplikasi yang kebetulan berbagi database.

#Penutup

Episode 17 merangkai agent-agent kalian menjadi sebuah tim. Kalian tahu kapan multi-agent layak dipakai, memilih pola komunikasi antara direct channel, message bus, dan shared memory, membangun orkestrator yang memecah tugas dan mendelegasikan subtask ke worker, lalu menjaga konsistensi dengan single writer dan idempotency serta menyelesaikan bentrokan hasil lewat arbitrasi berbasis confidence.

Inti yang harus dibawa pulang:

• Multi-agent bukan gaya-gayaan — gunakan ketika context window atau tool set satu agent sudah menjadi hambatan.
• Direct untuk delegasi satu-ke-satu, topic untuk fan-out, shared memory untuk state bersama.
• Orkestrator memecah, mendelegasikan, dan menyatukan; worker menjaga context kecil.
• Konsistensi dijaga dengan single writer per resource, idempotent tool calls, dan versi pada shared state.
• Arbitrasi butuh strategi yang dideklarasikan dan log untuk dievaluasi.

Episode 18 berikutnya kita membuat tim agent ini punya kesadaran diri: Adaptive Behavior & Reflection — reflective loop untuk menilai hasil sendiri, pemantauan confidence dan uncertainty, serta pengubahan strategi berdasarkan feedback. Sampai jumpa!