Memory, skills, or files? Where agent context belongs
An assistant that forgets everything is frustrating. An assistant that remembers an obsolete deployment plan as if it were current fact can be worse.
In the OpenClaw-to-Hermes transition post, I described wanting explicit homes for different kinds of context. This post turns that into a practical rule: store information according to how it will be used next, not merely because it might be useful someday.
This is the policy I want for my workflows, not a claim that Hermes forces every user to organize context this way.
Keep always-loaded memory small
Hermes’ built-in memory stores curated notes and a user profile. The documentation describes them as bounded stores loaded into the system prompt at session start. Skills, by contrast, can be loaded on demand.
That makes persistent memory a useful place for facts that matter across unrelated tasks: communication preferences, a stable timezone, or a general expectation about how work should be delivered.
It is a poor place for yesterday’s test result. That result might be accurate, but bringing it into every future conversation adds noise and invites a stale conclusion.
For project-specific conventions, I prefer project context or a relevant skill. “Use this repository’s test command” belongs near the workflow that needs it, not alongside facts the assistant needs for everything.
This is stricter than some examples in the memory documentation. The point is to keep my always-loaded context small enough that each entry earns its place.
Save procedures as skills
A skill should explain how to do a recurring kind of work. Hermes uses progressive disclosure: the agent can discover a skill from its description, load the procedure, and then open supporting references when needed.
For blog work, a useful skill might say:
Before continuing a series:
- Read the published roadmap and the existing drafts.
- Check implementation claims against current source material.
- Separate proposed behavior from implemented behavior.
- Keep operational endpoints and credentials out of the article.
- Verify the saved CMS draft before reporting success.
That procedure survives the task that taught it. A note saying “uploaded post 123 yesterday” does not.
The distinction also changes how I record a correction. If an image URL is rewritten by the site’s CDN, the reusable lesson is to verify the rendered image URL, not insist on a byte-for-byte match with the original URL. The failed request and debugging transcript belong in the task history.
Skills need maintenance too. A saved command can stop working, and a once-reasonable policy can outlive its purpose. Loading a skill should help an agent start intelligently; it should not prevent it from checking the current environment.
Put evidence in files
A draft, review result, test log, or submission manifest is an artifact. It deserves a file or another explicit system of record.
For this series, Markdown files hold the articles. The submission manifest records which WordPress post and media IDs belong to them. Those IDs are useful when retrying an upload or checking a saved draft, but they do not need to occupy permanent conversational memory.
The same applies to code review. A review artifact can record the revision examined and the findings produced. It should remain separate from a general preference about how reviews are written.
Files are not automatically authoritative. An old draft can say a feature is planned even after the repository implements it. The benefit is that an artifact has a location and can be compared with newer evidence. The agent still has to perform that comparison.
Use history to recover decisions, then recheck state
Session search answers questions like “why did we choose this approach?” It can recover the discussion without promoting every sentence of that discussion into permanent memory.
For “what is running now?”, history is only a lead. Inspect the deployment or another current source of truth. For “has this post been published?”, check WordPress rather than trust a conversation that ended with draft creation.
A compact decision rule is:
- Relevant across unrelated work: consider memory.
- Instructions for a recurring task: use a skill or project procedure.
- Evidence or output from one run: save an artifact.
- The reasoning behind an earlier decision: retrieve the history.
- A claim about current external state: check the external system.
There is one exclusion across all of these: secret values do not belong in general memory, skills, or blog artifacts. Keep credentials in an appropriate secret store and let procedures describe how authorized tools access them without copying their values.
I want an assistant that can recover the right context and show where it came from. Remembering more is only useful when it makes the next decision better.