Part 2: Context Loss — Why Every New Session Starts with Amnesia
60-second video version of this part.
Last time I made the case for a fleet: persist, specialise, parallelise. But before we can fix forgetting, we have to understand exactly why it happens. This is the layer where most agent projects quietly fail — not because the models are weak, but because nobody solved the memory problem.
What "context loss" actually is
A large language model is, at its core, a very good next-token predictor working on the text in front of it right now. It has no attachment to anything you said last week, because last week isn't in front of it. The "context" is content — the system prompt, your messages, tool results, all the things the session loaded into its working window.
Here is the key fact: a brand-new session starts mostly empty. Its context contains your system prompt and little else. Your business details, your preferences, your standing instructions, the decisions you made yesterday — none of it is there unless something explicitly puts it there.
So when you open a new chat and the assistant acts like a stranger, it is not glitching. It is behaving exactly as designed. Amnesia is not the bug — amnesia is the default. Memory is what you have to build on top.
The one-shot trap
The most dangerous version of this is the one-shot call. In Hermes you can run a task with a single detached query:
# Real: a one-shot, non-interactive query — fires once and is done
hermes chat -q "Summarize yesterday's meeting notes"
This is a fire-and-forget. It has no memory between calls — each one-shot is a fresh blank slate with only its own prompt. That is perfect for a throwaway question and a trap for anything with follow-up steps. If you build a workflow out of one-shots, every step re-learns everything from scratch, and cross-step context is simply gone.
You can see how this compounds across a whole team of agents. Five agents, each firing stateless one-shots, is five separate strangers with amnesia trying to cooperate on one mission. That is not a fleet. That is five isolated headless sharks.
The fix exists — and it's in two parts
Part one is persistent memory files that a session loads at start. Hermes keeps these per agent: a memory file holding the durable facts that should survive every session, and a user-profile file holding who the user is. This is the declarative layer — facts written once, read at every session start, so the blank slate is never actually blank.
Part two is named continuing sessions that carry real cross-message memory, instead of stateless one-shots:
# Real: run in a NAMED continuing session — this keeps memory across calls
hermes chat --continue my-writer-session --create-if-missing
Every build after this series leans on a "## Heading" structure with one rule: durable state lives in files, and sessions load it — they don't hold it by magic.
The prompt-based path
The CLI commands above are the direct route. If you'd rather describe the symptom and let an assistant diagnose and fix it, this is the prompt — one you could paste to Claude Code or to Hermes itself after noticing your AI "forgot" something:
My AI assistant keeps forgetting things between sessions — things I told it
yesterday, my preferences, decisions we made. I think this is because each
new session starts blank. Can you explain exactly why that happens in Hermes,
and then set me up with: (1) a persistent memory file it reads at the start
of every session, and (2) a named continuing session I can reuse instead of
one-off queries, so follow-up work doesn't reset to zero. Show me the real
commands, don't invent any config.
Why this prompt produces the Part 2 fix: it names both halves of the real fix without
you needing to know the terms "memory file" or "named continuing session" going in — you
just describe the symptom ("it forgot") and the constraint ("don't invent config"). An
assistant that understands Hermes will map "forgetting between sessions" to the
memories/MEMORY.md + USER.md pair and map "follow-up work resets" to the one-shot vs.
--continue distinction above — the same two mechanisms, reached by request instead of by
you reading the manual first.
Why this is the most important design decision
Everything else in an agent fleet — the specialists, the orchestrator, the dashboard — is bolted on top of the memory layer. Get memory wrong and no amount of clever orchestration helps, because every agent is still a stranger to itself between sessions. Get memory right and the whole fleet compound: past decisions, past mistakes, and standing preferences are shared, not re-derived.
The punchline for Part 2: amnesia is the default, and the fix is deliberate. You build memory by writing durable facts to files a session reads at start, and by using named continuing sessions instead of stateless one-shots. Do that first. Next time we take the first concrete step — standing up one orchestrator profile before any specialist exists.