Belajar Hermes AI Agent - Multi-turn Conversation & Context Handling

#Pendahuluan

Di episode 8 kalian membangun ingatan tiga lapisan: short-term, long-term, dan session state. Tapi percakapan nyata lebih rumit dari sekadar menyimpan — user berganti topik, menyela, lalu kembali lagi. Episode ini memoles cara Hermes menangani percakapan multi-turn dengan konteks yang selalu terkendali.

Roadmap episode ini: mengelola conversation state antar turn, context retrieval dan manajemen prompt window, serta menangani topic switch dan conversation reset.

#Conversation State Lintas Turn

Setiap percakapan di Hermes memiliki session_id. Semua turn yang berbagi session_id dianggap satu percakapan, dan state-nya dipertahankan antar turn — pesan baru ditambahkan ke riwayat, bukan menggantikannya.

turn 1  user  : Cek status ORD-2026-0142
turn 1  agent : Memeriksa... (panggil db.query) -> "Sedang dikirim"
turn 2  user  : Kapan sampai?
turn 2  agent : (riwayat turn 1 tersedia) -> "Estimasi 3 hari ke depan"

Di turn 2, agent memahami maksud "kapan sampai" karena state turn 1 masih utuh di session. Inilah inti multi-turn: jawaban bergantung pada konteks turn sebelumnya, bukan hanya pesan terakhir yang dikirim user.

Perpanjang satu langkah lagi: di turn 3 user bertanya "berapa ongkirnya?", dan agent menjawabnya dengan data order dari turn 1 tanpa user mengulang nomor order-nya. Konteks yang ditahan itulah yang membuat user bisa menyela dengan pertanyaan lain lalu kembali ke topik semula tanpa kehilangan thread — selama masih dalam session_id yang sama dan belum melewati batas turn yang dikonfigurasi.

#Context Retrieval di Setiap Turn

Sebelum setiap panggilan model, kernel merakit context dari berbagai sumber: riwayat turn terakhir, hasil retrieval long-term memory, dan data tool terbaru. Urutan dan proporsinya diatur agar model menerima informasi yang paling relevan.

export default defineHermesConfig({
  conversation: {
    retrieval: {
      enabled: true,
      maxResults: 5,
      minScore: 0.7,
      injectBefore: "history",
    },
    history: {
      mode: "sliding-window",
      maxTurns: 10,
    },
  },
});

conversation.retrieval menentukan berapa banyak entri memory yang disuntikkan dan di posisi mana, sementara history membatasi berapa turn riwayat yang masuk context. Keduanya adalah dua katup yang mengatur isi prompt window di setiap turn.

Contoh nyatanya: dengan maxResults: 5 dan minScore: 0.7, hanya fakta yang relevan yang ikut masuk prompt. Ketika topik berganti jauh, skor turun di bawah ambang dan entri lama tetap tersimpan di long-term memory — tidak dibuang, hanya tidak ikut disuntikkan sampai dibutuhkan lagi.

#Manajemen Prompt Window

Context window bukan sumber daya tak terbatas. Jika semua riwayat dikirim mentah-mentah, prompt penuh di turn 20 padahal percakapan baru setengah jalan. Manajemen prompt window berarti memutuskan apa yang masuk dan apa yang diringkas.

Hirarki prioritas isi prompt, dari yang tidak boleh hilang sampai yang paling mudah dibuang:

• System prompt — selalu dipertahankan utuh.
• Instruksi tugas saat ini — rencana yang sedang dieksekusi.
• Riwayat terbaru — beberapa turn terakhir, detail penuh.
• Riwayat lama — diringkas, bukan dibuang total.
• Hasil tool — cache ringkasannya, detail besar di long-term store.

Ketika total melebihi batas, kernel memangkas dari bawah: riwayat lama diringkas lebih dulu, baru yang lebih baru dipangkas. System prompt tidak pernah disentuh.

#Topic Switch & Conversation Reset

Tidak semua percakapan berjalan lurus. User bisa melompat dari "status order" ke "bagaimana cara refund" dalam satu sesi. Hermes mendeteksi pergeseran topik lewat relevansi antar turn dan memutuskan apakah perlu reset sebagian state.

hermes session reset --session ses_order-check

Reset penuh menghapus riwayat turn dan plan yang belum selesai, lalu memulai turn berikutnya dengan context bersih — system prompt tetap ada, long-term memory tetap tersimpan. Ini setara dengan "mulai percakapan baru" dari sisi user.

Contohnya: sesi support yang tadi menangani keluhan teknis direset sebelum user memulai topik refund yang sama sekali berbeda, sehingga jawaban agent tidak lagi tercemar konteks keluhan lama. System prompt dan instruksi tugas tetap utuh, jadi perilaku dasar agent tidak berubah.

#Konfigurasi Sesi Percakapan

Beberapa parameter sesi bisa disetel per use case. Sesi pendek cocok untuk chatbot dukungan; sesi panjang untuk research assistant yang menjelajah bertahap.

conversation:
  maxTurnsPerSession: 50
  idleTimeoutMinutes: 15
  onIdle: summarize-and-close
  topicSwitch:
    detection: auto
    action: soft-reset

Dengan onIdle: summarize-and-close, sesi yang menganggur 15 menit otomatis diringkas dan ditutup — menutup siklus yang dibangun di episode 8: riwayat dipadatkan, hal penting masuk long-term memory, dan sesi baru dimulai dengan bekal ingatan.

#Penutup

Multi-turn conversation adalah produk dari tiga hal yang berjalan bersamaan: conversation state yang dipertahankan antar turn, context retrieval yang menyuntikkan informasi relevan, dan manajemen prompt window yang menjaga semuanya di bawah batas. Kalian juga bisa mereset percakapan secara eksplisit saat topik berganti.

Inti yang harus dibawa pulang:

• session_id mempertahankan conversation state antar turn.
• Context dirakit ulang setiap turn: riwayat, retrieval, dan data tool.
• Prompt window dikelola dengan prioritas; system prompt tidak pernah dipangkas.
• Topic switch bisa ditangani dengan soft reset atau reset penuh.
• Sesi yang menganggur bisa otomatis diringkas dan ditutup agar memory tetap sehat.

Di episode 10 kita naik level ke Orchestration & Workflow Automation — menyusun multi-step workflow dengan tool berantai, task decomposition dan planning, serta error handling, retry pattern, dan fallback action. Sampai jumpa!