Honcho
Honcho is the profile and stateful-memory layer to consider when an agent should model changing people, agents, groups, projects, and ideas over time.
Routing Summary
Use Honcho when the task is user modeling, personalized agent behavior, or stateful memory across peers and projects. In Kevin's intended Hermes stack, Honcho should not compete with Hindsight Memory Provider for the external memory slot. Hindsight itself is only a selected runtime-memory candidate until its admission gate passes. Use Honcho through MCP/SDK, a separate profile, or a deliberate bridge when its peer-centric model is the distinct value.
What It Provides
The plastic-labs/honcho repository describes Honcho as memory infrastructure for stateful agents that understand changing people, agents, groups, projects, and ideas over time. It stores messages and events, reasons in the background, and can query peer representations, session context, search results, or natural-language insights. It can be used managed at api.honcho.dev or self-hosted as a FastAPI server. Source: plastic-labs/honcho, 2026-07-04
Its useful capabilities for Kevin's stack:
| Capability | Stack use |
|---|---|
| Reasoning-first memory | Keep derived conclusions separate from raw chat/session logs. |
| Peer-centric model | Model Kevin, agents, collaborators, projects, and ideas as changing entities. |
| Multi-peer perspective | Track what one agent/user knows about another when configured. |
| Managed or self-hosted | Choose cloud convenience or local control. |
| MCP / agent integrations | Attach memory to clients such as Claude Code, OpenCode, OpenClaw, Hermes, and Cursor-compatible clients. |
MCP And CLI
Honcho docs position the MCP server as the fastest path for adding memory to tools that support MCP. The setup pattern is: get an API key, add the remote MCP server config, and set a user name header. The CLI is available via uv tool install honcho-cli and supports honcho init and honcho doctor for connectivity checks. Source: Honcho docs, 2026-07-04
Kevin Stack Decision
For Hermes Mac Mini Agent OS, Honcho is best treated as the user-profile and identity-modeling layer. It is especially interesting for building a durable model of Kevin's preferences, working style, project context, and agent-to-agent continuity.
The canonical writeback rule still applies: if Honcho learns a fact, preference, workflow, or correction that future agents should rely on, promote it into Kevin-Wiki or the appropriate skill/config surface. Honcho is a modeling system; the wiki is the durable source of truth.
Boundary With Hindsight
Hermes memory providers are single-select. After Hindsight Memory Provider passes pinned install, model/data-path, bank, doctor, leakage, usefulness, and recovery proof, it is the preferred external runtime-memory slot for hybrid recall and explicit reflection. Honcho should be attached only where its peer/user-modeling layer is needed, such as MCP/SDK access, a separate Hermes profile, or a controlled bridge. Do not silently run two memory systems that can both answer "who is Kevin?" with conflicting profiles.
Do Not Use For
- Replacing the wiki's
USER.md,SOUL.md, or qmd retrieval. - Storing secrets or browser auth state.
- Letting derived user models mutate agent behavior without a visible writeback path.
- Adding a second memory backend to Hermes without an explicit provider boundary.
Timeline
- 2026-08-11 | Corrected the deployment boundary after the Hindsight v0.9.0 replay: Honcho remains the separate peer/profile-modeling candidate, while Hindsight is selected but not called active until its full memory admission and recovery gate passes. Source:
vectorize-io/hindsight@d7c33fde; local capability audit - 2026-07-04 | Added Honcho as the peer/user-modeling memory layer for Kevin's Hermes operator stack, distinct from Hindsight's intended external Hermes memory-provider slot. The 2026-08-11 replay made that slot selected-but-inactive until admission proof passes. Source: User request, 2026-07-04;
plastic-labs/honcho