feat: Honcho memory integration (opt-in)#38
Conversation
|
Can you link me to more info on Honcho I havent heard of it to know what it adds vs the USER.md user profile that the agent already builds on their user |
|
So USER.md is creating conclusions similar to how Honcho does, yes. To be clear, my PR currently runs alongside it -- I'll make one more commit to integrate them cleanly (still opt-in) if you'reinterested. Important to note-- the reasoning Honcho does is powered by Neuromancer which was specifically fine-tuned for this task. (link to evals here) There's also dreaming -- the reasoning model ambiently makes conclusions and fills in the gaps between sessions. It's a better way to form identity, all accessible in the cloud (remap anything on the fly) or self-hosted with your own model infra. I'm using Honcho as a bridge between all of my agentic interactions and that's the most valuable part for me. The peer-peer architecture also lets you control which peers can make conclusions about other peers -- super helpful for agentic orchestration going forward. Happy to discuss more -- erosika on Discord / @3rosika on Twitter. |
Opt-in persistent cross-session user modeling via Honcho. Reads ~/.honcho/config.json as single source of truth (shared with Claude Code, Cursor, and other Honcho-enabled tools). Zero impact when disabled or unconfigured. - honcho_integration/ package (client, session manager, peer resolution) - Host-based config resolution matching claude-honcho/cursor-honcho pattern - Prefetch user context into system prompt per conversation turn - Sync user/assistant messages to Honcho after each exchange - query_user_context tool for mid-conversation dialectic reasoning - Gated activation: requires ~/.honcho/config.json with enabled=true
When Honcho is active: - System prompt uses Honcho prefetch instead of USER.md - memory tool target=user add routes to Honcho - MEMORY.md untouched in all cases When disabled, everything works as before. Also wires up contextTokens config to cap prefetch size.
USER.md stays in system prompt when Honcho is active -- prefetch is additive context, not a replacement. Memory tool user observations write to both USER.md (local) and Honcho (cross-session) simultaneously.
6430f5b to
70d1abf
Compare
|
Okay, after reviewing I like it a lot. I'll add more documentation on it after merge - Thanks! |
…e integration, setup CLI Authored by erosika. Builds on #38 and #243. Adds async write support, configurable memory modes, context prefetch pipeline, 4 new Honcho tools (honcho_context, honcho_profile, honcho_search, honcho_conclude), full 'hermes honcho' CLI, session strategies, AI peer identity, recallMode A/B, gateway lifecycle management, and comprehensive docs. Cherry-picks fixes from PRs #831/#832 (adavyas). Co-authored-by: erosika <erosika@users.noreply.github.com> Co-authored-by: adavyas <adavyas@users.noreply.github.com>
feat: polish send button — hidden until content, icon-circle, pop-in animation
|
Investigated and resolved. The pi-bridge service is running correctly with the stdio JSON Director handler at (v0.3.0). The .env correctly specifies . An orphaned pre-ESM-migration Director tmux session was also cleaned up. Closing as resolved - the system is operational. |
|
Investigated and resolved. The pi-bridge service is running correctly with the stdio JSON Director handler (v0.3.0). The .env correctly specifies the path to director-bridge.js. An orphaned pre-ESM-migration Director tmux session was also cleaned up. Closing as resolved - the system is operational. |
…gration feat: Honcho memory integration (opt-in)
…session title integration, setup CLI Authored by erosika. Builds on NousResearch#38 and NousResearch#243. Adds async write support, configurable memory modes, context prefetch pipeline, 4 new Honcho tools (honcho_context, honcho_profile, honcho_search, honcho_conclude), full 'hermes honcho' CLI, session strategies, AI peer identity, recallMode A/B, gateway lifecycle management, and comprehensive docs. Cherry-picks fixes from PRs NousResearch#831/NousResearch#832 (adavyas). Co-authored-by: erosika <erosika@users.noreply.github.com> Co-authored-by: adavyas <adavyas@users.noreply.github.com>
…session title integration, setup CLI Authored by erosika. Builds on NousResearch#38 and NousResearch#243. Adds async write support, configurable memory modes, context prefetch pipeline, 4 new Honcho tools (honcho_context, honcho_profile, honcho_search, honcho_conclude), full 'hermes honcho' CLI, session strategies, AI peer identity, recallMode A/B, gateway lifecycle management, and comprehensive docs. Cherry-picks fixes from PRs NousResearch#831/NousResearch#832 (adavyas). Co-authored-by: erosika <erosika@users.noreply.github.com> Co-authored-by: adavyas <adavyas@users.noreply.github.com>
…gration feat: Honcho memory integration (opt-in)
…session title integration, setup CLI Authored by erosika. Builds on NousResearch#38 and NousResearch#243. Adds async write support, configurable memory modes, context prefetch pipeline, 4 new Honcho tools (honcho_context, honcho_profile, honcho_search, honcho_conclude), full 'hermes honcho' CLI, session strategies, AI peer identity, recallMode A/B, gateway lifecycle management, and comprehensive docs. Cherry-picks fixes from PRs NousResearch#831/NousResearch#832 (adavyas). Co-authored-by: erosika <erosika@users.noreply.github.com> Co-authored-by: adavyas <adavyas@users.noreply.github.com>
…gration feat: Honcho memory integration (opt-in)
…gration feat: Honcho memory integration (opt-in)
…session title integration, setup CLI Authored by erosika. Builds on NousResearch#38 and NousResearch#243. Adds async write support, configurable memory modes, context prefetch pipeline, 4 new Honcho tools (honcho_context, honcho_profile, honcho_search, honcho_conclude), full 'hermes honcho' CLI, session strategies, AI peer identity, recallMode A/B, gateway lifecycle management, and comprehensive docs. Cherry-picks fixes from PRs NousResearch#831/NousResearch#832 (adavyas). Co-authored-by: erosika <erosika@users.noreply.github.com> Co-authored-by: adavyas <adavyas@users.noreply.github.com>
…working) Deploy NousResearch#38's captured probe error named the cause exactly: from inside the gateway container, "ssh: connect to host 127.0.0.1 port 22: Connection refused" — the prod compose runs the containers on a BRIDGE network (as the health-gate comments already document), so the container's loopback is its own, not the host's. The host-side denial probe connecting fine confirms sshd is up on the host. Fix: - docker-compose.prod.yml: add extra_hosts host.docker.internal:host-gateway on the gateway service and set HERMES_FLEET_HOST=host.docker.internal, so the in-container fleet client targets the host's gateway address. Correct under both bridge and host networking. - deploy bootstrap: pin the host's public host keys under BOTH names (host.docker.internal for bridge-networked prod, 127.0.0.1 for host-networking setups) in the volume known_hosts. If the next run still can't connect, the captured probe error will say whether it's now a firewall filter on the docker subnet rather than a wrong address. https://claude.ai/code/session_018vp1LDdpoaRLCNZQRsnAp8
mrjohnyhats
left a comment
There was a problem hiding this comment.
Hermes Agent Review
Reviewed from first principles against the PR spec: opt-in Honcho, ~/.honcho/config.json as the source of truth, non-fatal optional dependency, additive USER.md behavior, prefetch/sync/query integration. I found two correctness/privacy blockers and one config-precedence bug. Since this PR is already merged, these should be follow-up fixes rather than merge blockers here.
Automated check run locally: python -m compileall honcho_integration tools/honcho_tools.py run_agent.py model_tools.py toolsets.py hermes_cli/config.py gateway/run.py passed.
| _session_key: str | None = None # Current session key (e.g., "telegram:123456") | ||
|
|
||
|
|
||
| def set_session_context(session_manager, session_key: str) -> None: |
There was a problem hiding this comment.
AIAgent alive at a time (different chats, platforms, or overlapping tool loops). The last agent to call set_session_context() wins, so query_user_context can answer using another user's/session's Honcho context, and the availability check_fn can also be stale. This violates the user-model isolation that the feature needs. Please make the tool handler receive per-call agent/session context (or register a per-agent closure/context object) rather than shared module state.
| path = config_path or GLOBAL_CONFIG_PATH | ||
| if not path.exists(): | ||
| logger.debug("No global Honcho config at %s, falling back to env", path) | ||
| return cls.from_env() |
There was a problem hiding this comment.
~/.honcho/config.json with enabled=true and that the global Honcho config is the single source of truth. But when the config file is absent or invalid this falls back to from_env(), which sets enabled=True. That means any process with HONCHO_API_KEY in the environment will start syncing conversations to Honcho without an explicit enabled=true config. Please keep env as an API-key fallback only after an explicit config opt-in, or have from_env() default to disabled unless a dedicated opt-in env/config flag is present.
| linked_hosts=linked_hosts, | ||
| enabled=raw.get("enabled", False), | ||
| save_messages=raw.get("saveMessages", True), | ||
| context_tokens=raw.get("contextTokens") or host_block.get("contextTokens"), |
There was a problem hiding this comment.
💡 Config precedence bug: the module docstring/spec says host-specific settings win over flat/global settings, but contextTokens is resolved in the opposite order (raw before host_block). If a user sets a global budget and a Hermes-specific override, the Hermes override is ignored. This should mirror workspace/aiPeer precedence: host_block.get("contextTokens") or raw.get("contextTokens").


Cross-session user modeling via Honcho. Hermes builds a persistent representation of who it's talking to -- preferences, patterns, context -- and carries that understanding across conversations. A model of the user.
Three integration points: prefetch user context into the system prompt each turn, sync exchanges for ongoing modeling, and a dialectic reasoning tool (
query_user_context) for the agent to actively query its understanding of the user mid-conversation.honcho_integration/reads~/.honcho/config.jsonas single source of truth. All imports lazy, all calls non-fatal. Optional dependency, zero behavior change when disabled.Composes with USER.md
Both systems run in tandem. USER.md stays in the system prompt as the agent's local, curated snapshot of the user. Honcho prefetch is additive -- synthesized cross-session context layered on top.
When the agent writes to
memory(target="user", action="add"), observations go to both USER.md (local file) and Honcho (cross-session reasoning model). MEMORY.md (agent's own notes) is untouched in all cases.When Honcho is disabled, USER.md works exactly as before. Nothing changes.
Prefetch size is configurable via
contextTokensin the global config -- caps how much user context Honcho surfaces per turn. No value = uncapped.