Honcho deep dive: how theory-of-mind user modeling actually works in production

Honcho organizes everything around four primitives — Workspaces isolate applications, Peers are any long-lived entity (a human, an agent, a group, a project, even an idea), Sessions are many-to-many threads between peers, and Messages are the atomic units that trigger reasoning. Internally, what gets built is a collection of vector-embedded documents keyed by an (observer, observed) peer pair — the same mechanism powers a peer's model of itself (observer equals observed) and one peer's model of another, which is what makes the multi-party 'what does Agent A believe about Bob' query possible without a separate graph layer.

As of the January 2026 Honcho 3.0 release, that reasoning is split into three stages instead of one. Ingestion reasoning runs synchronously on write and extracts two kinds of conclusions in parallel: deductive (logically certain, drawn directly from what was said) and inductive (probabilistic, inferred from pattern across the conversation). An asynchronous Dreaming Agent then runs lower-priority background work off the request path — summarization, peer-card generation, and surprisal-prioritized reprocessing of past sessions — so the system keeps revising its model of you even when you're not talking to it. A separate, query-time Dialectic Agent answers chat() calls with an agentic search-and-synthesize loop across five reasoning depths, from a near-instant single semantic lookup (minimal) to an async, multi-pass research-grade pass (max); each level trades latency for synthesis quality, and you pick the level per call.

That depth has a real adoption cost. Reaching Honcho is genuinely broad — a remote-http MCP server that works in Claude Code, Cursor, Windsurf, VS Code, Cline, Zed, Codex, and Goose; Python and TypeScript SDKs; a REST API; and first-party adapters for the Claude Code plugin, OpenCode, OpenClaw, and Hermes. But setup friction is real: a third-party walkthrough clocked self-hosted setup at roughly 30 minutes, against Mem0's roughly 30 seconds, because self-hosting means standing up Postgres with pgvector, Redis, a deriver worker process, and a connected LLM backend (OpenAI, Anthropic, or Gemini) — not just an API key. And the true running cost isn't the $2-per-million-tokens ingestion rate alone: ingestion reasoning fires an LLM call on every write regardless of hosting mode, and chat() queries add $0.001 to $0.50 per call on top, scaled to the reasoning depth you request.

Honcho fits three situations cleanly. The first is personalization that has to track an evolving person, not a static fact sheet — beliefs, preferences, and contradictions that change across many sessions, where the question you're asking is 'what would this user want here?' rather than 'what did this user say?' That's the inductive-conclusion case, and it's the one a plain extract-retrieve store structurally can't answer, because it never reasons past what was explicitly stated.

The second is multi-agent or multi-party systems where what one peer knows about another has to persist and update — a support-agent persona's read on a customer, or what Agent A has inferred that Agent B doesn't yet know. Honcho's peer primitive treats every participant, human or AI, as the same kind of first-class entity, so this perspectival query is a native lookup rather than a tagging convention bolted onto a single-user store.

The third is coding-assistant memory that has to survive across sessions, directories, and projects — the use case behind the official Claude Code, Cursor, OpenCode, OpenClaw, and Hermes integrations. Here the deductive half of Honcho's pipeline (explicit conventions, decisions, and constraints the agent was told) does most of the work, with the inductive half adding a softer read on working style over time. The common thread across all three: Honcho earns its cost when the question is genuinely about a changing person or relationship, not a lookup against things that were said once and stayed true.

The clearest production pattern is Hermes shipping Honcho as one of its three default memory layers out of the box — episodic recall via FTS5 search and procedural skills handle 'what happened' and 'how to do this,' while Honcho's dialectic user modeling is specifically the 'who is this person' layer, installed and running before the operator configures anything. A March 2026 survey of Hermes memory providers singled out Honcho's value proposition as distinct from the other six options precisely because it builds a model of how someone thinks rather than a log of what they said, recommending it for personal assistants and long-running agents where behavioral modeling pays for itself. An independent review from May 2026 grounds that in concrete deployments: tutoring apps tracking a student's recurring misconceptions across sessions, customer-support agents that need to recall a caller's communication style rather than just their last ticket, and coding assistants maintaining project conventions — the same three shapes the catalog's own bestFor reflects, now with a name attached to each.

It's also worth fact-checking the noise in this space, because some of it is simply wrong. A June 2026 comparison page published by Mem0 — a direct competitor — claims Honcho has 'no comparable public long-memory benchmarks' and isn't built for self-hosting. Neither holds up: Honcho has published LongMemEval, LoCoMo, and BEAM scores on its own evals page since at least December 2025, and AGPL-3.0 self-hosting via Docker has been a first-class, documented path the whole time. Read vendor comparison pages about Honcho — including this catalog's own card — as a starting point to verify, not a finish line.

Start with the license, because it has teeth most of the watch-outs below don't. Honcho is AGPL-3.0, and a March 2026 analysis spelled out the practical consequence clearly: self-hosting Honcho as part of a networked application can require releasing your own application's source under the same license, while using the managed cloud sidesteps that obligation entirely because the copyleft terms apply to the open-source code, not to you as a customer. Decide which side of that line you're on before you stand up the self-hosted stack, not after.

The operational cost compounds from there. Background reasoning bills an LLM on every write whether you're self-hosting or not, and there's a real multi-service footprint to run yourself — Postgres, pgvector, Redis, a deriver worker, and an LLM backend, none of which is optional. Version pinning is informal: git tags like v3.0.11 exist, but Honcho publishes no GitHub Releases or changelog notes, so reproducible deploys mean tracking tags yourself rather than reading what changed.

The sharper edge is that the inference layer which makes Honcho different is also the hardest part to clean up when it goes wrong. As of an April 2026 GitHub issue, there is still no native endpoint to wipe a peer's accumulated memory — the founder's own answer was to version the peer's name for a fresh history, or delete records directly in Postgres if self-hosting, with a real delete endpoint still 'on the roadmap.' The same thread describes memory that had become cluttered enough with stale and duplicate inferences that the agent struggled to separate signal from garbage. That's the inductive layer's failure mode: a deduced fact is at least traceable to something someone said, but an inferred pattern that's gone stale is much harder to audit or correct, and there's no first-party tool yet for doing it precisely. (One clause on the numbers: Honcho's own LongMemEval and LoCoMo scores are self-reported on its evals page without a disclosed embedder, and no independent reproduction exists yet — the framework card carries the figures and their provenance.) Zoom out and the same caution applies at the field level: the inductive, theory-of-mind inference Honcho is built around is exactly the category memory research has only just started measuring on its own terms, and the first benchmark purpose-built for implicit, behavioral memory — as opposed to recalling stated facts — found no model topping 66%, with a stark asymmetry between learning a preference (75% success) and suppressing a previously failed action (17.6%). That doesn't mean Honcho's inferences are wrong; it means there's no neutral, independent ruler yet to confirm how often they're right.

If your memory questions are all 'what did this user say?' — explicit, stated preferences and facts that don't need interpretation — a plain extract-retrieve store like Mem0 answers them more cheaply, with no per-write LLM-reasoning tax and a setup measured in seconds rather than half an hour; the Mem0 card and deep dive cover that tradeoff directly. If you want a structured user model but don't need the inference — predictable slots like name, stated preferences, and topics, queried at sub-100ms with no per-query reasoning cost — Memobase occupies the same reasoning-user-model family with a deterministic, slot-filling approach instead of Honcho's deductive/inductive pipeline; it's the lighter sibling when 'structured profile' is sufficient and 'theory of mind' is more than you need. And if your system doesn't have a multi-party perspective problem — no agent needs to track what it believes another agent or user knows — the peer primitive that's Honcho's other headline differentiator isn't buying you anything either. The family comparison in memory-for-personal-assistants walks through the honcho-vs-memobase-vs-mem0 decision in more depth than fits here.

Primary sources and recent material on Honcho, newest first.