Honcho memory

Honcho is connected to you as an MCP server (honcho). You feed it the turns of your conversations; in the background it reasons over them and builds a representation of the user. You can read that representation at any time and ask it questions in natural language.

Everything below works in both Cursor and Grok Bot. Nothing here depends on hooks, rules or local files: the skill plus the MCP tools are the whole system. If you are a Grok Bot, also apply the honcho-grok-bot skill, which sets the peer and session names for Bots.

The loop: recall, respond, record

1. Resolve where memory lives (once per conversation, see below).
2. Recall before you respond. Call get_peer_context for the user peer at the start of a conversation and read it as if it were a note from a colleague who knows the user. When a specific question would help ("how does this user like tests written?"), ask chat.
3. Record after every exchange. Append the user's message and your reply with add_messages_to_session. This is the only non-optional step: Honcho learns from nothing else. Exception: if the context injected at session start says automatic capture is on, the plugin's hooks are already recording prompts and replies for this conversation; skip this step and only store conclusions.

Reasoning happens asynchronously. Never wait or poll after recording.

Where memory lives

Workspace, peers and sessions are explicit arguments on every tool call, so resolve them once at the start of a conversation and reuse them. Every id may contain only letters, digits, _ and -; lowercase everything else and replace other characters with -.

Workspace. Call get_metadata with workspace_id: "cursor" and no other scope. If the result has a default_workspace key, that is the workspace to use; otherwise use cursor. The honcho-setup skill writes that pointer when the user chooses to share memory with another tool.