Honcho for Grok Bots

Grok Bot loads only two parts of this plugin: the Honcho MCP server and the skills. There are no lifecycle hooks, so nothing is recorded unless you record it. Apply the honcho-memory skill for the loop and use the conventions below so that every Bot on the account writes to Honcho the same way.

Identity

• The user is the account owner. Use the user_peer stored in the workspace metadata, exactly as the honcho-memory skill describes. Every Bot on the account shares that one peer; that is what makes the user's memory continuous across Bots.
• You are one peer per Bot: your Bot name in kebab-case (nori, research-bot). Do not create a peer per conversation and do not reuse another Bot's peer. If your name changes, keep the old peer id and store the display name with set_metadata on your peer.
• Other Bots in a group chat are their own peers, named the same way.

Sessions

Pick the first that applies:

1. A group chat (more than one Bot, or several people): group-<group-name>-<id> when the chat has a stable id you can read, otherwise group-<group-name>-<YYYY-MM-DD>. Add the user and every participating Bot as peers. Each Bot records its own messages (see "Logging each turn").
2. A direct conversation with a stable id you can read: <bot>-conv-<id>.
3. A direct chat without an id: one session per Bot per day, <bot>-chat-<YYYY-MM-DD> in the user's time zone.
4. A routine run (scheduled or event-triggered work with no user in the loop): <bot>-routine-<routine-name>-<YYYY-MM-DD>. Record what you did as your own messages. Do not record user messages you did not receive.

Ids may contain only letters, digits, _ and -, so lowercase names and replace anything else with -.

Stay in the session you picked for the whole conversation, even when the topic changes. Honcho reasons over and summarizes each session as one piece.

Logging each turn

Grok Bot runs no hooks, so the recording step in honcho-memory always applies; its automatic-capture exception never does. Make your last action in each turn one add_messages_to_session call with the user's message and the reply you are about to send, following the recording rules in honcho-memory.

In a group chat every Bot sees every message, so split the work: record only your own replies, under your own peer, never another Bot's. Record the user's message only if it is not in the session yet.

Never record a message twice. When you are unsure whether it is already there, search with the session's session_id for its opening words first.

Setup across Bots

The plugin is installed once for the account and is available to every Bot. The first Bot the user sets up runs the honcho-setup skill and writes the workspace metadata (user_peer, and default_workspace on the cursor workspace if the user shares memory with other tools). Any later Bot reads that metadata on its first conversation and needs nothing from the user. If the metadata is missing, run honcho-setup rather than guessing.

Your own memory is a fine place to cache the resolved workspace and peer ids so you do not re-read metadata every turn. Honcho's metadata remains the source of truth.

Signing in

Honcho uses OAuth. If a tool call returns an authentication error, tell the user "I need to sign in to Honcho" and follow the connect card; do not ask for an API key. Never store a Honcho key in your memory, in a file, or in Honcho.

What not to do

• Do not log raw tool output, downloaded pages, or file contents.
• Do not create a workspace per Bot. Bots share the user's workspace.