optional-skills/autonomous-ai-agents/honcho/SKILL.md
Configure and use Honcho memory with Hermes -- cross-session user modeling, multi-profile peer isolation, observation config, and dialectic reasoning. Use when setting up Honcho, troubleshooting memory, managing profiles with Honcho peers, or tuning observation and recall settings.
npx skillsauth add nousresearch/hermes-agent honchoInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Honcho provides AI-native cross-session user modeling. It learns who the user is across conversations and gives every Hermes profile its own peer identity while sharing a unified view of the user.
hermes honcho setup
# select "cloud", paste API key from https://app.honcho.dev
hermes honcho setup
# select "local", enter base URL (e.g. http://localhost:8000)
See: https://docs.honcho.dev/v3/guides/integrations/hermes#running-honcho-locally-with-hermes
hermes honcho status # shows resolved config, connection test, peer info
Honcho models conversations as interactions between peers. Hermes creates two peers per session:
peerName): represents the human. Honcho builds a user representation from observed messages.aiPeer): represents this Hermes instance. Each profile gets its own AI peer so agents develop independent views.Each peer has two observation toggles that control what Honcho learns from:
| Toggle | What it does |
|--------|-------------|
| observeMe | Peer's own messages are observed (builds self-representation) |
| observeOthers | Other peers' messages are observed (builds cross-peer understanding) |
Default: all four toggles on (full bidirectional observation).
Configure per-peer in honcho.json:
{
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": true }
}
}
Or use the shorthand presets:
| Preset | User | AI | Use case |
|--------|------|----|----------|
| "directional" (default) | me:on, others:on | me:on, others:on | Multi-agent, full memory |
| "unified" | me:on, others:off | me:off, others:on | Single agent, user-only modeling |
Settings changed in the Honcho dashboard are synced back on session init -- server-side config wins over local defaults.
Honcho sessions scope where messages and observations land. Strategy options:
| Strategy | Behavior |
|----------|----------|
| per-directory (default) | One session per working directory |
| per-repo | One session per git repository root |
| per-session | New Honcho session each Hermes run |
| global | Single session across all directories |
Manual override: hermes honcho map my-project-name
How the agent accesses Honcho memory:
| Mode | Auto-inject context? | Tools available? | Use case |
|------|---------------------|-----------------|----------|
| hybrid (default) | Yes | Yes | Agent decides when to use tools vs auto context |
| context | Yes | No (hidden) | Minimal token cost, no tool calls |
| tools | No | Yes | Agent controls all memory access explicitly |
Each Hermes profile gets its own Honcho AI peer while sharing the same workspace (user context). This means:
hermes profile create coder --clone
# creates host block hermes.coder, AI peer "coder", inherits config from default
What --clone does for Honcho:
hermes.coder host block in honcho.jsonaiPeer: "coder" (the profile name)workspace, peerName, writeFrequency, recallMode, etc. from defaulthermes honcho sync # creates host blocks for all profiles that don't have one yet
Override any setting in the host block:
{
"hosts": {
"hermes.coder": {
"aiPeer": "coder",
"recallMode": "tools",
"observation": {
"user": { "observeMe": true, "observeOthers": false },
"ai": { "observeMe": true, "observeOthers": true }
}
}
}
}
The agent has 4 Honcho tools (hidden in context recall mode):
honcho_profileQuick factual snapshot of the user -- name, role, preferences, patterns. No LLM call, minimal cost. Use at conversation start or for fast lookups.
honcho_searchSemantic search over stored context. Returns raw excerpts ranked by relevance, no LLM synthesis. Default 800 tokens, max 2000. Use when you want specific past facts to reason over yourself.
honcho_contextNatural language question answered by Honcho's dialectic reasoning (LLM call on Honcho's backend). Higher cost, higher quality. Can query about user (default) or the AI peer.
honcho_concludeWrite a persistent fact about the user. Conclusions build the user's profile over time. Use when the user states a preference, corrects you, or shares something to remember.
Config file: $HERMES_HOME/honcho.json (profile-local) or ~/.honcho/config.json (global).
| Key | Default | Description |
|-----|---------|-------------|
| apiKey | -- | API key (get one) |
| baseUrl | -- | Base URL for self-hosted Honcho |
| peerName | -- | User peer identity |
| aiPeer | host key | AI peer identity |
| workspace | host key | Shared workspace ID |
| recallMode | hybrid | hybrid, context, or tools |
| observation | all on | Per-peer observeMe/observeOthers booleans |
| writeFrequency | async | async, turn, session, or integer N |
| sessionStrategy | per-directory | per-directory, per-repo, per-session, global |
| dialecticReasoningLevel | low | minimal, low, medium, high, max |
| dialecticDynamic | true | Auto-bump reasoning by query length. false = fixed level |
| messageMaxChars | 25000 | Max chars per message (chunked if exceeded) |
| dialecticMaxInputChars | 10000 | Max chars for dialectic query input |
| Key | Default | Description |
|-----|---------|-------------|
| injectionFrequency | every-turn | every-turn or first-turn |
| contextCadence | 1 | Min turns between context API calls |
| dialecticCadence | 1 | Min turns between dialectic API calls |
Run hermes honcho setup. Ensure memory.provider: honcho is in ~/.hermes/config.yaml.
Check hermes honcho status -- verify saveMessages: true and writeFrequency isn't session (which only writes on exit).
Use --clone when creating: hermes profile create <name> --clone. For existing profiles: hermes honcho sync.
Observation config is synced from the server on each session init. Start a new session after changing settings in the Honcho UI.
Messages over messageMaxChars (default 25k) are automatically chunked with [continued] markers. If you're hitting this often, check if tool results or skill content is inflating message size.
| Command | Description |
|---------|-------------|
| hermes honcho setup | Interactive setup wizard (cloud/local, identity, observation, recall, sessions) |
| hermes honcho status | Show resolved config, connection test, peer info for active profile |
| hermes honcho enable | Enable Honcho for the active profile (creates host block if needed) |
| hermes honcho disable | Disable Honcho for the active profile |
| hermes honcho peer | Show or update peer names (--user <name>, --ai <name>, --reasoning <level>) |
| hermes honcho peers | Show peer identities across all profiles |
| hermes honcho mode | Show or set recall mode (hybrid, context, tools) |
| hermes honcho tokens | Show or set token budgets (--context <N>, --dialectic <N>) |
| hermes honcho sessions | List known directory-to-session-name mappings |
| hermes honcho map <name> | Map current working directory to a Honcho session name |
| hermes honcho identity | Seed AI peer identity or show both peer representations |
| hermes honcho sync | Create host blocks for all Hermes profiles that don't have one yet |
| hermes honcho migrate | Step-by-step migration guide from OpenClaw native memory to Hermes + Honcho |
| hermes memory setup | Generic memory provider picker (selecting "honcho" runs the same wizard) |
| hermes memory status | Show active memory provider and config |
| hermes memory off | Disable external memory provider |
development
Use when you have a spec or requirements for a multi-step task. Creates comprehensive implementation plans with bite-sized tasks, exact file paths, and complete code examples.
development
Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.
development
Use when encountering any bug, test failure, or unexpected behavior. 4-phase root cause investigation — NO fixes without understanding the problem first.
development
Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).