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

#Introduction

In episode 8 you built a three-layer memory: short-term, long-term, and session state. But real conversations are more complicated than just storing — users switch topics, interrupt, and then come back. This episode polishes how Hermes handles multi-turn conversations with context that always stays under control.

Here is the roadmap for this episode: managing conversation state across turns, context retrieval and prompt window management, and handling topic switches and conversation resets.

#Conversation State Across Turns

Every conversation in Hermes has a session_id. All turns that share a session_id are considered one conversation, and its state is maintained across turns — new messages are appended to the history, not replacing it.

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"

In turn 2, the agent understands the meaning of "when will it arrive" because the turn 1 state is still intact in the session. This is the core of multi-turn: answers depend on the context of previous turns, not just the last message the user sent.

Extend it one step further: in turn 3 the user asks "what is the shipping cost?", and the agent answers using the order data from turn 1 without the user repeating the order number. That retained context is what lets the user interrupt with another question and then return to the original topic without losing the thread — as long as it stays in the same session_id and does not exceed the configured turn limit.

#Context Retrieval on Every Turn

Before every model call, the kernel assembles context from various sources: recent turn history, long-term memory retrieval results, and fresh tool data. Their order and proportion are managed so the model receives the most relevant information.

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

conversation.retrieval determines how many memory entries are injected and in which position, while history limits how many turns of history enter the context. These are the two valves that regulate the prompt window contents on every turn.

A concrete example: with maxResults: 5 and minScore: 0.7, only relevant facts enter the prompt. When the topic shifts far away, the score drops below the threshold and the old entries stay in long-term memory — not discarded, just not injected until they are needed again.

#Prompt Window Management

The context window is not an unlimited resource. If all history were sent raw, the prompt would be full by turn 20 even though the conversation is only halfway through. Prompt window management means deciding what goes in and what gets summarized.

The priority hierarchy of prompt contents, from what must never be lost to what is easiest to drop:

• System prompt — always kept intact.
• Current task instructions — the plan being executed.
• Recent history — the last few turns, in full detail.
• Old history — summarized, not thrown away entirely.
• Tool results — a cached summary, with large details in the long-term store.

When the total exceeds the limit, the kernel trims from the bottom: old history is summarized first, and only then is newer history trimmed. The system prompt is never touched.

#Topic Switch & Conversation Reset

Not every conversation runs straight. A user can jump from "order status" to "how does refund work" within one session. Hermes detects topic shifts through the relevance between turns and decides whether a partial state reset is needed.

hermes session reset --session ses_order-check

A full reset removes the turn history and unfinished plans, then starts the next turn with a clean context — the system prompt stays, and long-term memory remains stored. This is equivalent to "starting a new conversation" from the user's side.

For example: a support session that was handling a technical complaint is reset before the user starts a completely different refund topic, so the agent's answers are no longer contaminated by the old complaint context. The system prompt and task instructions stay intact, so the agent's base behavior does not change.

#Conversation Session Configuration

Several session parameters can be tuned per use case. Short sessions suit support chatbots; long sessions suit a research assistant that explores gradually.

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

With onIdle: summarize-and-close, a session idle for 15 minutes is automatically summarized and closed — closing the cycle built in episode 8: history is condensed, important things enter long-term memory, and a new session starts equipped with memory.

#Conclusion

Multi-turn conversation is the product of three things running together: conversation state maintained across turns, context retrieval injecting relevant information, and prompt window management keeping everything under the limit. You can also explicitly reset the conversation when the topic changes.

Key takeaways:

• session_id maintains conversation state across turns.
• Context is reassembled on every turn: history, retrieval, and tool data.
• The prompt window is managed with priorities; the system prompt is never trimmed.
• Topic switches can be handled with a soft reset or a full reset.
• Idle sessions can be automatically summarized and closed to keep memory healthy.

In episode 10 we level up to Orchestration & Workflow Automation — building multi-step workflows with chained tools, task decomposition and planning, plus error handling, retry patterns, and fallback actions. See you there!