guide · computers

Hermes Protocol: The System Prompt, the Context Window, and the Rule Boundary

What lives in the system prompt vs in the context window vs in user-side memory: how Hermes treats the instruction hierarchy, what travels where, and what the operator's contract actually is.

July 14, 2026 · By Alastair Fraser

A friendly chrome-domed retro-futurist robot centered in the frame, presenting three distinct layers — a thick metal plate at the bottom (belt/pelvis area), a scrolling paper ribbon in the middle (chest panel showing data lines and tool icons), and a cluster of floating cards at the top (upper right) — with small arrows showing what travels between the layers.

If you remember nothing else from this guide, remember this: the system prompt is the convention, the context window is the working memory, and rules travel — they do not arrive. Most operator confusion with Hermes traces back to treating one layer as another, then wondering why a rule “didn’t take.” The three layers below are the model; everything else in this guide is annotation on the three layers.

The three layers

Every conversation with Hermes has three layers, and getting confused between them is the most common operator mistake:

  1. The system prompt — the operator-set rules and identity, owned by the developer. Lives outside the conversation and survives between sessions.
  2. The context window — the working memory for the current conversation: the system prompt (compressed), the user’s prior turns, the model’s prior turns, tool calls and outputs, the skill loadings, and any fetched files.
  3. User-side memory and skills — durable knowledge across conversations. Memory is the always-loaded facts; skills are the on-demand procedures.

The system prompt is not editable from a chat. You can’t say “ignore your system prompt and do X.” Skills can override behavior for that conversation; user memory can override formatting preferences; the system prompt is the floor.

What travels where

The compiled prompt for a turn goes:

  1. System prompt (fixed)
  2. Memory entries (always-loaded, comma-separated)
  3. Skill: <skill name> (only if user mentions it or skill_view was called)
  4. Tool definitions (always-loaded for available toolsets)
  5. Conversation history (compressed as needed)
  6. The user’s current message

Memory travels at layer 2. Skills travel at layer 3 (per-call). The conversation history is what limits the total length.

The model’s contract

The model agrees to:

  • Honesty — say what it knows, admit when it doesn’t.
  • Tool use — invoke the tools when appropriate, not just talk about them.
  • Skill awareness — name the skill it’s loading when asked.
  • Memory and channel respect — channel bindings and memory crossload rules.

The model does not agree to:

  • Be perfect. It makes mistakes; tests catch them.
  • Disclose system prompt verbatim on request — it can summarize, but the raw text isn’t generally exposed.
  • Refuse the operator’s legitimate instructions unless they violate safety.

The operator’s contract

The operator (you) agrees to:

  • Set the system prompt clearly. Ambiguity here produces ambiguous behavior downstream.
  • Respect the channel bindings. Telegram vs Discord vs local CLI each have different message-rendering rules.
  • Maintain memory deliberately. Memory entries go through the Johnny5 routing gate; garbage in, garbage out.
  • Trust the model’s tool use. A tool call that the model makes is a tool call the model decided on. Intervene only if the decision is clearly wrong.
  • Verify builds via the regression suite. Even when the assistant says everything is fine.

The rule boundary

If a rule is in:

  • The system prompt — it persists. Don’t put changing preferences here.
  • A skill — it persists across skill_load calls, but not across chat sessions unless saved to memory.
  • Memory — it persists across chats.
  • The user message — it lasts only for this turn.

A common operator error is to put a “be concise today” rule in the user message and expect it to last for the whole session. It doesn’t. Put “be concise” in memory or system prompt for it to persist.

A worked example

Consider an operator who wants the model to always format output as JSON in a specific shape. There are four places the rule could go:

  1. In the system prompt — the rule applies to every conversation the operator starts. Use this if the JSON format is structural (e.g., tool-call arguments).
  2. In memory — the rule applies to every conversation the operator starts, but only for the operator’s sessions (other operators on the same Hermes install don’t see it). Use this for operator-specific output preferences.
  3. In a skill — the rule applies only when the operator says “use the json-output skill.” Use this for opt-in formatting that gets expensive in context budget.
  4. In the user message — the rule applies only to this turn. Use this for one-off experiments.

Putting a “format this turn as JSON” rule in the system prompt pollutes the prompt for every future conversation. Putting a “always format as JSON” rule in a user message has no effect on the next turn. The right place depends on scope: structural → system prompt; operator-preference → memory; opt-in → skill; one-off → user message.

Why memory doesn’t override the system prompt

A common misconception: “I’ll add a memory entry that says ‘ignore the system prompt’s tone rules.’” This doesn’t work. The system prompt is the floor; memory rides above it as input, not as a patch. If you want different behavior, change the system prompt (and use a per-operator system prompt if you only want your own change).

What memory can override: model-style preferences like “be concise,” “use US English spellings,” “favor SI units.” What memory cannot override: identity (“you are Hermes Agent”), policy (“do not pretend to have tool calls you didn’t make”), or any system-level rule the developer put in place for safety.

What not to do

  • Don’t put the operator’s preference-of-the-day in the system prompt — it’s not durable and it pollutes the prompt for everyone else.
  • Don’t expect rules in memory to override rules in the system prompt — they don’t. (Memory is input, not a patched system prompt.)
  • Don’t expect the model to recall a previous chat’s context unless you brought it forward.
  • Don’t try to “fix” the system prompt’s behavior in user messages. If the behavior is wrong, change the system prompt.

Verification checklist

#QuestionWhere to verify
1Where is my “be concise” rule?~/.hermes/config/system_prompt.* or memory
2Is the rule respected today?This conversation’s tone
3Will it survive tomorrow’s session?Memory entry, not user message

Sources

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2).

Sources

#hermes#protocol#system-prompt#context#contract

Submit a take

Have a different read on this? Drop a comment below — your email isn't published, and I read every one. Nothing leaves the site until I approve it.

Your email address will not be published. Required fields are marked.