Belajar Hermes AI Agent - Orchestration & Workflow Automation

#Pendahuluan

Di episode 9 kalian belajar menjaga konteks percakapan multi-turn tetap hidup dan terkendali. Tapi agent yang hanya menjawab pertanyaan belum melakukan pekerjaan. Episode 10 menaikkan level: kalian akan membuat agent menyelesaikan pekerjaan multi-langkah — merencanakan, memanggil tool secara berantai, dan pulih sendiri ketika sebuah langkah gagal.

Roadmap episode ini: membangun multi-step workflow dengan chained tools, task decomposition dan planning, lalu error handling, retry patterns, dan fallback actions.

#Workflow: Lebih dari Sekadar Rantai Tool Call

Di episode 6 kalian melihat pola chaining sederhana: web.search lalu web.fetch. Orchestration membawa pola itu ke tingkat berikutnya — alur dengan banyak langkah, keputusan di tengah jalan, dan penanganan kegagalan per langkah.

Contoh klasik: agent yang menangani tiket komplain.

1. cari user di database        -> db.query
2. ambil riwayat order terakhir -> db.query
3. cek status pengiriman        -> http.get ke tracking API
4. simpulkan penyebab komplain  -> model
5. susun jawaban + saran        -> model
6. kirim balasan ke user        -> http.post (perlu konfirmasi)

Perhatikan ada keputusan: kalau status pengiriman tidak ditemukan di langkah 3, alur tidak boleh berlanjut ke langkah 4 memakai data kosong. Inilah yang membedakan orchestration dari sekadar memanggil banyak tool secara acak — setiap langkah tahu langkah mana yang mendahuluinya dan apa yang harus dilakukan bila hasilnya tidak sesuai.

#Mendefinisikan Workflow dalam Profile

Hermes memungkinkan mendefinisikan workflow secara deklaratif di dalam config agent. Setiap langkah punya id, tool yang dipakai, dan aturan lanjutnya.

workflow:
  steps:
    - id: find_user
      tool: db.query
      args: { query: "SELECT * FROM users WHERE id = {userId}" }
    - id: last_order
      tool: db.query
      args: { query: "SELECT * FROM orders WHERE user_id = {lastUserId} ORDER BY created_at DESC LIMIT 1" }
    - id: check_shipping
      tool: http.get
      args: { url: "https://api.courier.example.com/track/{order.tracking}" }
    - id: summarize
      tool: model.generate
      args: { prompt: "Rangkum status komplain dari data di atas" }

Setiap langkah memakai output langkah sebelumnya lewat placeholder, jadi alurnya berantai secara eksplisit. Versi ini memakai pola {userId} untuk nilai yang datang dari input user, dan {order.tracking} untuk hasil langkah sebelumnya. Workflow deklaratif punya keuntungan besar: mudah dibaca, mudah di-version control, dan mudah diuji per langkah. Parameter seperti max_attempts untuk batas ulang percobaan nanti kita tambahkan di bagian error handling.

#Task Decomposition dan Planning

Tidak semua pekerjaan bisa ditulis sebagai workflow statis. Saat user memberi perintah besar dan terbuka, agent harus memecahnya sendiri — ini disebut task decomposition. Hermes melakukannya lewat mode planning: sebelum mengeksekusi apa pun, agent menyusun rencana sub-tugas dan urutannya.

hermes run agents/ops.yml --plan --session ops-1

Dengan flag --plan, controller menyuruh agent menulis rencana dulu: daftar sub-tugas, tool yang dibutuhkan tiap sub-tugas, dan dependensi antar sub-tugas. Setelah rencana disetujui, baru eksekusi dimulai. Ini mencegah agent "menembak dari pinggul" dan melewatkan langkah penting.

Pola decomposition yang sehat:

• Break down by output — setiap sub-tugas menghasilkan satu artefak yang bisa diverifikasi (laporan, angka, file).
• Tentukan dependensi — sub-tugas yang butuh hasil sub-tugas lain tidak boleh jalan duluan.
• Batasi kedalaman — terlalu banyak level justru menambah overhead. Untuk sebagian besar tugas, 3-5 sub-tugas cukup.

#Error Handling dalam Workflow

Langkah workflow bisa gagal dengan berbagai alasan: tool error, data tidak ada, API timeout, atau model menolak format. Error handling di orchestration berarti mendefinisikan apa yang terjadi per jenis kegagalan, bukan membiarkan seluruh workflow berhenti.

on_error:
  not_found:
    - match: { tool: "db.query", error: "no rows" }
      action: complete
      response: "User tidak ditemukan. Minta email untuk verifikasi."
  timeout:
    - match: { error: "timeout" }
      action: retry
      max_attempts: 2
      backoff_ms: 1500
  rate_limited:
    - match: { error: "rate_limit" }
      action: fallback
      fallback: cache_answers

Pisahkan penanganan berdasarkan jenis error: data yang tidak ditemukan adalah kondisi normal (selesaikan dengan jawaban yang aman), timeout layak di-retry, rate limit diarahkan ke jawaban cache. Error yang tidak dikenal jatuh ke handler default: berhenti dan lapor ke user, jangan diproses lanjut dengan data kosong. Nilai seperti backoff_ms menentukan jeda awal sebelum percobaan ulang.

#Retry Patterns dan Fallback Actions

Retry tidak boleh dilakukan asal-asalan. Tiga pola yang perlu kalian kenal:

• Fixed retry — ulangi dengan jeda tetap. Sederhana, tapi bisa memperparah overload saat semua request membanjir di waktu yang sama.
• Exponential backoff — jeda bertambah tiap percobaan: 1 detik, 2 detik, 4 detik. Lebih ramah ke provider yang sedang tertekan.
• Jitter — acak kecil jeda untuk mencegah gelombang retry dari banyak klien bertabrakan. Kombinasi backoff dan jitter adalah standar industri.

export async function withRetry(fn, config) {
  let delay = config.baseMs;
  for (let attempt = 0; attempt <= config.maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (attempt === config.maxAttempts) throw err;
      const jitter = Math.random() * delay * 0.3;
      await sleep(delay + jitter);
      delay *= 2;
    }
  }
}

Fallback action adalah jaring pengaman terakhir: kalau retry gagal juga, workflow tidak boleh berhenti tanpa hasil. Contoh: cache_answers untuk rate limit, jawaban "layanan sedang sibuk, coba lagi nanti" untuk timeout berulang, atau eskalasi ke manusia untuk error yang tidak bisa dipulihkan. Pilihan fallback yang tepat membuat agent tetap berguna bahkan saat infrastruktur di belakangnya bermasalah — topik yang akan kita dalami dengan circuit breaker di episode 14.

#Penutup

Orchestration mengubah agent menjadi pekerja nyata: workflow deklaratif merangkai tool secara berantai dengan output tiap langkah mengalir ke langkah berikutnya; task decomposition memecah perintah besar menjadi rencana; dan error handling, retry, serta fallback membuat alur tetap selesai meski ada langkah yang gagal.

Inti yang harus dibawa pulang:

• Workflow deklaratif merangkai langkah dan dependensinya dalam satu config yang bisa di-version control.
• Planning dengan --plan memaksa agent menyusun sub-tugas sebelum mengeksekusi.
• Setiap jenis error ditangani berbeda: not found, timeout, dan rate limit tidak diperlakukan sama.
• Retry memakai exponential backoff dengan jitter, bukan jeda tetap tanpa pikir panjang.
• Fallback action memastikan workflow menghasilkan sesuatu yang aman walau semua retry gagal.

Di episode 11 kita mengamankan semua kekuatan ini: Security & Access Control — mengamankan akses tool dan API keys, membatasi capability ke operasi yang aman, plus audit trail dan policy enforcement. Sampai jumpa!