honcho — Wednesday’s shared long-term memory
Category: mcp
Where it works: Claude Code · Telegram (Hermes uses it natively for memory) — both
Source: _infra/mcp/servers/honcho/server.py → Honcho server on Jarvis (192.168.0.100:8005), workspace wednesday, peer sabin
What it is
The cross-runtime memory layer. It accumulates a peer card (durable facts about you, derived from conversation over time) + stores sessions/messages, so any Wednesday runtime can recall who you are and what was decided — not start fresh. This is what makes Telegram-Wednesday “remember where we left off.”
How to trigger it
You rarely call it by name — Wednesday queries it for you. Natural language that pulls it: “what do you know about me?”, “what did we decide about X?”, “have we discussed Y?”, “remember that Z”. On Hermes it’s automatic (memory provider).
How to use it
Ask Wednesday a memory question and she runs the right honcho tool. To deliberately
seed a fact, say “remember that honcho_add_observation.
Tools
| tool | what it does | example |
|---|---|---|
honcho_get_peer_card | read the accumulated key-facts about a peer | ”what do you know about me?” |
honcho_chat | dialectic Q&A — reasons over derived memory (reasoning: minimal→max) | “what’s my stance on background Claude?” |
honcho_search | semantic search across all stored sessions | ”find when we discussed split-DNS” |
honcho_get_messages | read messages in a specific session | ”show the messages from session X” |
honcho_list_peers | list known peers | (discovery) |
honcho_list_sessions | list all sessions in the workspace | (discovery / audit) |
honcho_add_observation | write a one-off fact about a peer | ”remember that I prefer Telegram for mobile” |
Notes / limits
The deriver/dialectic LLM runs on Grok (via the Hermes proxy) — cheap, not Claude. The peer card is derived (grows as you talk; a fresh fact may take a bit to surface). Embeddings off by default. Honcho server lives on Jarvis — if it’s down, recall degrades (Wednesday still works, just without long-term memory).