Reasoning / user model2 frameworks · 3 use cases

Reasoning / user model

Models a person or agent, not a pile of facts.

These systems maintain an evolving model of the user (or of an agent, or of an idea) by reasoning in the background over what they have observed. They infer preferences, beliefs, and contradictions rather than only storing stated facts. Recall is less keyword-match and more 'what would this user likely need here' — the gap between recalling a stated preference and predicting a reaction.

What makes this family unique

Every other family stores and retrieves. This one derives. It is the only family whose core operation is reasoning over accumulated observations to update a picture of who someone is and what they want — which is what makes a long-lived assistant feel like it knows you, and the only native model of perspective in multi-agent settings (agent A's view vs agent B's view).

Frameworks in this family

2 catalogued.

Honcho

Plastic Labs

5.7k

Reasoning / user model

Peer-centric memory built on four primitives: Workspaces (app-level isolation), Peers (any long-lived entity — user, agent, group, project, or idea), Sessions (many-to-many interaction threads between peers), and Messages (data units that trigger reasoning). A background deriver worker ('dreaming') asynchronously extracts conclusions and peer representations using configurable LLM backends (OpenAI, Anthropic, Gemini); queries target the derived knowledge layer rather than raw message history.

Self-host: heavyFreemiumAGPL-3.0

Best for: Personalization that must model a user's evolving beliefs, preferences, and contradictions over many sessions (theory-of-mind, not fact recall) · Multi-agent or multi-party systems where what peer A knows about peer B — or what an AI agent knows about a human — needs to persist and update · Coding-assistant memory (Claude Code plugin, Cursor MCP) where context must survive across sessions, directories, and projects

View memory card →

Memobase

2.8kStale

Reasoning / user model

Profile-based long-term memory backend that extracts and consolidates conversation turns into structured user profile slots (topics, preferences, facts) stored in PostgreSQL. Incoming data is queued in a Redis buffer and batch-processed by an LLM into the profile, decoupling write cost from request latency. At read time the pre-compiled profile is returned via SQL lookup (sub-100ms); an event timeline of timestamped entries sits alongside the profile and supports full-text and tag-based search. Self-hostable via Docker Compose (FastAPI + Postgres + Redis); managed cloud also available.

Self-host: moderateFree + paidApache-2.0

Best for: Chat applications and AI companions requiring persistent, structured user profiles (preferences, topics, facts) at sub-100ms retrieval latency · Multi-session educational tutors, customer-service bots, or voice agents (LiveKit adapter available) where long-term user history must be structured and queryable · Teams wanting a self-hostable or cloud-managed memory REST backend with multi-language SDKs and an MCP server for IDE or agent integration

View memory card →

Use cases this family is built for

Top-down recommendations from the use-case playbook. Each names the one binding constraint that picks the tool, the primary pick (which may sit in another family when the case spans more than one), and runner-ups.

Personal assistant that knows you over time

Binding constraint: Build an evolving model of a person, not a pile of facts — answer 'what would this user actually want / believe here.'

Pick

Honcho — The only tool in the reasoning family. Its background deriver infers preferences, beliefs, and contradictions and lets you query them in natural language — the gap between recalling a stated fact and predicting a reaction.

Runner-up

Memobase — If you only need a structured profile (name, prefs, attributes), not reasoning — cheaper and more predictable, weaker on nuance.

From Agentic Memory: Use-Case Playbook 2026 · last verified 2026-06-28

Multi-agent system with shared or perspectival memory

Binding constraint: Model 'what does agent A know vs agent B,' or 'what does the support persona think the customer wants.'

Pick

Honcho — The peer primitive (agents and ideas can be peers, many-to-many sessions) is the only native model of perspective.

Runner-up

Mem0 — A shared store with clean agent_id/run_id isolation — but no perspective modeling.

From Agentic Memory: Use-Case Playbook 2026 · last verified 2026-06-28

Cost-sensitive, high-volume ingestion

Binding constraint: Lots of data, tight budget.

Pick

Memori — Drops the vector DB and runs on SQL + LLM extraction — ~80–90% cheaper infra than vector-backed stores.

Runner-ups

OpenViking — Tiered L0/L1/L2 loading gives ~80–90% token savings on reads. Pick this when cost is per-call tokens, not infrastructure.
Honcho — Also cheap at $2/1M ingested if managed is acceptable.

From Agentic Memory: Use-Case Playbook 2026 · last verified 2026-06-28

Last verified 2026-06-28 · updated by manual-stub