Introduction
User profiling is the part of Hermes that turns a generic assistant into a personal one. With profiling on, the agent watches the conversation for stable facts about you (your role, your style, your habits) and writes them into USER.md. The next session starts with those facts already in the system prompt. The agent no longer has to ask how you like things done.
Key Concepts
USER.md: The profile file in~/.hermes/memories/, with a capacity around 1,375 characters (~500 tokens).- Passive learning: Profiling happens during normal conversation; you do not have to fill out a form.
- Stable facts only: One-off moods or session-specific events are not profiled.
- Frozen at session start: Like all persistent memory, profile updates appear at the next launch, not mid-session.
Real World Context
A designer who works with Hermes across web and Figma plugin projects keeps reminding the agent "please give me code-first answers, not prose". After a few sessions with profiling enabled, the agent stops needing the reminder. "User prefers code-first answers with minimal prose" lives in USER.md. The reminder budget that used to go into restating preferences now goes into actual work.
Deep Dive
Profiling is a small subset of the broader memory write triggers, narrowed to the user-target. It captures:
- Identity: name, role, organization context (when stated).
- Communication style: terse vs verbose, formal vs casual, code-first vs prose-first.
- Technical context: primary languages, comfort level, tools regularly used.
- Workflow habits: how you commit, how you test, whether you want confirmation before destructive actions.
- Timezone or working hours (when stated).
It deliberately does not capture:
- Project-specific facts (those go in
MEMORY.md, notUSER.md). - Sensitive personal information (medical, financial, anything obviously private).
- Mood or single-conversation emotional state.
- Things that contradict prior stable facts without an explicit correction.
The split between USER.md and MEMORY.md is intentional. USER.md is about you and follows you across every project. MEMORY.md is about your environment and changes when your environment changes. A new laptop should rewrite a lot of MEMORY.md. It should not touch USER.md.
Profiling is gated by a single config key (memory.user_profile_enabled). Turning it off does not delete USER.md; it just stops the agent from writing new entries into it. You can also edit USER.md by hand at any time, and many users do exactly that to set the initial profile rather than waiting for the agent to learn it slowly.
Common Pitfalls
- Confusing profile with project memory: If the fact would change when you switch jobs or laptops, it does not belong in
USER.md. - Treating profiling as a substitute for explicit preferences: For high-leverage preferences ("never use emdashes"), a hand-written
USER.mdentry is faster and more reliable than waiting for the agent to infer it.
Best Practices
- Seed
USER.mdmanually on day one: Five lines you write yourself save weeks of passive learning. - Audit it monthly: Profiling is good but not perfect. A two-minute read catches drift and lets you refine wording.
Summary
- User profiling is the subsystem that writes into
USER.mdbased on stable facts about you. - It captures identity, style, technical context, and habits; it skips project specifics and sensitive data.
- Profile updates land on disk immediately but appear in the system prompt at the next session start.
- A handful of hand-written entries beats waiting for the agent to learn slowly.
Code Examples
# User
## Profile
- Olivier, senior backend engineer, Europe/Paris timezone.
- Comfortable in Go and TypeScript; intermediate in Rust.
## Style
- Wants code-first answers, prose only where the why is non-obvious.
- Never use emdashes; rewrite as periods, colons, or parentheses.
- Confirm before any rm -rf, force-push, or destructive migration.