Run Hermes with Clear Context, Durable Memory, and Cost Controls
Reliable Hermes work starts before the first tool call. Give the agent a concrete outcome, the relevant file paths or source locations, observed errors, expected behavior, constraints, and a definition of done. The official guidance recommends front-loading this context rather than stretching discovery across several clarification rounds. It also recommends describing the result you need instead of prescribing every click, because Hermes can search files, run tools, and iterate on evidence.[1]
Shape requests for execution
A useful request separates five things: goal, scope, evidence, constraints, and verification. Paste tracebacks or exact error text when available. Name what may be changed and what must remain untouched. Ask for a readback, test, or other concrete check rather than accepting a claim that work is complete.
Put recurring project rules in AGENTS.md, not in every prompt. Keep that file focused: top-level context is loaded at session start, and repeatedly injected context consumes tokens. Durable personality belongs in SOUL.md; repository conventions, test commands, and workflow rules belong in project context.[1]
Store facts and procedures differently
Use memory for facts such as preferences, environment details, and project locations. Use skills for repeatable procedures and multi-step recipes—“what” belongs in memory; “how” belongs in a skill. Memory is deliberately bounded and may be consolidated, so replace stale facts instead of adding contradictory versions. A memory write reaches disk immediately, but the session’s prompt snapshot does not refresh mid-session; start a new session before testing whether a new memory is active.[1]
Control context and cost
Stable system context and conversation history can benefit from provider prompt caching. Repeated model switches, provider fallback, or credential rotation can force a full-price reread of a long conversation. Use /usage to inspect token consumption, /insights for broader usage patterns, and /compress when a long session slows down or approaches its context limit. Batch mechanical operations where practical, and delegate independent reasoning-heavy work so intermediate material does not flood the main conversation.[1]
Keep approvals meaningful
Use an isolated container backend for unfamiliar repositories or untrusted code. On host execution, treat dangerous-command approval as a safety boundary: prefer a one-time or session approval until the pattern is well understood, and avoid permanently allowlisting broad destructive patterns. Container backends rely on the container as the boundary, so the image and mounts still need deliberate hardening. Messaging bots with tool access should use explicit user allowlists or pairing rather than open access.[1]
Operating checklist
- State the outcome, scope, inputs, constraints, and definition of done.
- Put stable project rules in a concise
AGENTS.md. - Store facts in memory and reusable procedures in skills.
- Check
/usageand compress long sessions before context degrades. - Avoid unnecessary model switching inside a long conversation.
- Confirm execution isolation, approval scope, and messaging access controls.
Common pitfalls
- Asking to “fix it” without an error, location, or expected behavior.
- Filling persistent context with temporary notes that raise cost every turn.
- Assuming a memory edit changes the already-running session prompt.
- Switching models repeatedly and losing prompt-cache savings.
- Choosing a permanent approval for a pattern that has not been reviewed.
- Running unfamiliar code on the host simply because an agent generated it.
Verification
Review the agent’s final evidence, not only its narrative. Confirm that requested tests or readbacks actually ran, inspect /usage after a representative workflow, and start a fresh session to verify new memory or context behavior. For risky work, confirm the selected terminal boundary and the exact access audience before enabling automation.