Memory

9.3. Technical Environment

The “environment facts” part of MEMORY.md

This is the most native kind of MEMORY.md content: information about the system, servers, and tools in use that the agent needs to know again each time, otherwise it has to rediscover them from scratch.

Real examples

This server runs Debian 12 with PostgreSQL 16.
User is on macOS 14 Sonoma, Homebrew, and has both Docker Desktop and Podman. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.
Staging server (10.0.1.50) requires SSH on port 2222, not 22. Key is at ~/.ssh/staging_ed25519.

That last example is a classic “lesson learned” entry: exactly the kind of fact that takes several turns to discover the first time, but only one line to remember forever.

The rule of grouping related facts into one entry

When you are getting close to the size limit, an efficient style is to combine multiple related facts into one dense entry, as in the macOS example above, which packs four separate facts into one line: operating system, package manager, container tool, and editor. That is much more space-efficient than four separate entries.

Practical lessons

• Prioritize storing “non-obvious discoveries” such as a nonstandard SSH port, an API quirk, or a limitation of a specific tool. Those are the most expensive facts to rediscover.
• Do not store things that are easy to look up again, such as “Python 3.12 supports nested f-strings.” Hermes can web search that at any time, so it is not worth spending space from the fixed ~800-token budget.
• In complex multi-project environments with many codebases, remember that MEMORY.md is shared across the whole profile. If one project has too many project-specific technical details, consider splitting it into a separate profile (section 19.4) instead of trying to cram everything into the same 2,200 characters.