Урок 13.7. Honcho: peer-centric memory для stateful agents

План лекции

Сначала мы разберем, какую проблему решает Honcho: agents need to understand changing people, agents, groups, projects and ideas over time. Затем рассмотрим его ключевую модель: workspace, peer, session, message, conclusions, representations and peer cards.

После этого разберем Honcho Loop: store, reason, query, inject. Особое внимание уделим background reasoning, observer/observed peer pairs and representation endpoint for low-latency context. В конце обсудим self-hosting, AGPL license implications, подходящие сценарии and риски peer-centric memory.

Цель лекции

Понять Honcho как memory infrastructure for stateful agents, где память строится вокруг peers and evolving representations, а не только вокруг documents, user profiles or Markdown skills.

Ожидаемый результат

После лекции читатель понимает:

почему peer-centric model важна для multi-agent and social AI systems;
как Honcho хранит messages and events in sessions;
что делает background deriver;
чем conclusions отличаются от representations;
как context endpoint helps long-running conversations;
какие вопросы нужно задать перед self-hosting Honcho.

Короткая карточка инструмента

Поле	Значение
Repository	https://github.com/plastic-labs/honcho
Docs	https://docs.honcho.dev
Product/API	https://honcho.dev
Stars snapshot	около 6.5k на 2026-08-08 по GitHub page
Primary language	Python
License	AGPL-3.0
Category	Memory infrastructure for stateful agents
Core server	FastAPI
Main storage	Postgres with pgvector for self-hosted setup

Honcho позиционируется как memory infrastructure для агентов, которые должны понимать меняющихся людей, агентов, группы, проекты and идеи во времени. Его центральная особенность - peer-centric model.

Почему peer-centric memory отличается от user profile

User profile обычно отвечает на вопрос:

Что система знает о пользователе?

Peer-centric memory задает более широкий вопрос:

Что разные участники знают друг о друге, о себе и о контексте взаимодействия?

В простом chatbot есть один user and один assistant. Но в современных системах часто есть:

пользователь;
несколько AI agents;
команда;
проект;
reviewer;
tutor;
customer account;
persona;
group chat.

Если все это свести к одному user_id, память станет плоской. Honcho делает peer базовой сущностью: peer может быть human или AI agent.

Core concepts

Concept	Объяснение
`Workspace`	Top-level container, изолирует use cases and tenants.
`Peer`	Участник системы: human user, AI agent, group, project or idea.
`Session`	Conversation context; many-to-many with peers.
`Message`	Atomic unit: peer-to-peer communication or document chunk.
`Conclusion`	Вывод, который Honcho извлек о peer.
`Representation`	Low-latency snapshot of what Honcho knows about peer.
`Peer Card`	Compact identity summary.
`Context`	Prompt-ready bundle from session messages, conclusions and summaries.

Эта модель ближе к социальной памяти, чем к документному RAG. Honcho интересуется не только "какой chunk релевантен?", но и "какой representation участника сформировался?".

Honcho Loop

README описывает цикл Honcho так: store conversations/events/documents/tool traces, reason in background, query context/search/representations/insights, inject result into any LLM call.

flowchart TD S[Store messages and events] --> Q[Background queue] Q --> R[Reasoning deriver] R --> C[Conclusions] R --> P[Representations] R --> SUM[Session summaries] ASK[Application query] --> OUT{Need} OUT -->|Insight| CHAT[Peer chat] OUT -->|Fast context| REP[Representation] OUT -->|Long session| CTX[Session context] OUT -->|Search| SRCH[Hybrid search] CHAT --> INJ[Inject into LLM] REP --> INJ CTX --> INJ SRCH --> INJ

Важная деталь: storage is synchronous, insights are asynchronous. Вы можете записать messages immediately, но reasoning может догонять позже.

Workspaces, peers, sessions, messages

Honcho storage primitives образуют понятную иерархию:

flowchart TD W[Workspace] --> P1[Peer Alice] W --> P2[Peer Tutor Agent] W --> P3[Peer Reviewer Agent] W --> S1[Session 1] W --> S2[Session 2] P1 --- S1 P2 --- S1 P1 --- S2 P3 --- S2 S1 --> M1[Messages] S2 --> M2[Messages]

Sessions and peers have many-to-many relationship. Это важно для multi-party interactions. Один peer участвует в разных sessions, одна session может включать нескольких peers.

Messages маркируются source peer. Благодаря этому Honcho может рассуждать, кто что сказал, кто кого наблюдал, and какие conclusions относятся к какому peer.

Observer and observed pairs

Самая интересная деталь Honcho - internal collections keyed by (observer, observed) peer pairs.

Это позволяет моделировать:

self-representation: что Alice знает о себе;
agent representation: что tutor-agent знает об Alice;
cross-peer model: что peer X understands about peer Y;
group or project perspective.

flowchart LR A[Alice] --> AA[(Alice about Alice)] T[Tutor Agent] --> TA[(Tutor about Alice)] R[Reviewer Agent] --> RA[(Reviewer about Alice)] A --> AT[(Alice about Tutor)]

Для companion, tutor, team and multi-agent scenarios это очень сильная модель. Разные участники могут иметь разные representations, и это нормально.

Conclusions and representations

Honcho exposes insights through several surfaces.

Conclusions - это extracted deductive and inductive statements about a peer. Их можно воспринимать как структурированные выводы из истории.

Representation - это static snapshot for low-latency use. Оно нужно, когда агенту нужен context быстро and deterministic enough. README отмечает, что newly added messages may take time to appear in chat/representation responses because background reasoning is asynchronous.

Peer Card - compact identity summary.

Session context - prompt-ready bundle for long-running conversations, including messages, conclusions and summaries under token limit.

В production это удобно: разные latency budgets can use different API surfaces.

Context endpoint для long-running conversations

Long-running sessions быстро заполняют context window. Honcho предоставляет context endpoint, который возвращает combination of messages, conclusions and summaries up to token limit.

Это похоже на memory compaction:

raw messages + summaries + peer conclusions -> prompt-ready context

Такой endpoint полезен для:

tutors;
companions;
support agents;
roleplay agents;
team assistants;
multi-session product workflows.

Важно, что context is not just search results. Он собирается around session and peer model.

Hybrid search

Honcho также поддерживает hybrid search BM25 + vector at workspace, session or peer level. Это закрывает классические retrieval tasks:

найти прошлое сообщение;
найти похожий document chunk;
найти relevant interaction in a session;
найти evidence for a conclusion.

Но в Honcho search - не единственный public surface. Он соседствует с representations and natural-language peer chat.

Это отличает Honcho от memory frameworks, которые сводят все к vector search.

Background reasoning and deriver

Self-hosted Honcho запускает API server and background worker called deriver. Deriver обрабатывает queue and generates representations, summaries, peer cards and manages other background tasks.

Архитектурно это важно:

expensive reasoning не блокирует write path;
можно масштабировать workers;
queue status можно инспектировать;
свежесть representation становится измеримым параметром.

Но это добавляет operational complexity. В отличие от lightweight SDK, Honcho - server system with database, migrations, workers and provider keys.

Integrations

Honcho поддерживает Python SDK, TypeScript SDK, MCP, Claude Code plugin, OpenCode, OpenClaw, Hermes and other MCP clients.

Это отражает два use cases:

Use case	Integration
Add memory to product	Python/TypeScript SDK
Give coding agent persistent memory	Plugin or MCP
Self-host infrastructure	FastAPI server + Postgres/pgvector
Long-running chat	context endpoint
Peer insight query	peer chat / representation

Для product team SDK важнее. Для power user/coding setup - MCP or plugin.

Self-hosting and license

Honcho open source under AGPL-3.0. Для self-hosting README описывает Docker quickstart and local development setup. Основные components:

FastAPI server;
Postgres with pgvector;
database migrations via Alembic;
background deriver worker;
LLM provider keys;
optional auth, monitoring, telemetry, vector store config.

AGPL-3.0 важно учитывать юридически. Если вы модифицируете server and предоставляете его как network service, лицензия может накладывать obligations. Для коммерческого продукта это надо обсудить с legal team.

Типы памяти из курса

Тип памяти	Как Honcho его закрывает
Semantic memory	Conclusions and representations about peers.
Episodic memory	Sessions and messages over time.
Reflection memory	Background reasoning and derived conclusions.
Shared memory	Multi-peer sessions and workspaces.
World memory / RAG	Uploaded files and hybrid search.
Procedural memory	Не основной фокус, но process conclusions can encode habits.

Honcho особенно силен в social and relational memory. Он хорошо подходит, когда нужно моделировать participants, not just facts.

Мини-кейс: AI tutor

AI tutor должен помнить не только "Alice studies algebra". Ему важно понимать:

как Alice учится;
на каких задачах застревает;
какие объяснения помогают;
как tutor-agent уже пробовал объяснять;
какой другой agent проверял homework.

В Honcho это можно представить:

sequenceDiagram participant Alice participant Tutor participant Honcho participant LLM Alice->>Tutor: Не понимаю квадратные уравнения Tutor->>Honcho: add messages in session Honcho-->>Tutor: background conclusions later Tutor->>Honcho: representation Alice Honcho-->>Tutor: learning style and gaps Tutor->>LLM: prompt with context LLM-->>Alice: personalized explanation

Здесь peer representation полезнее простого list of facts. Tutor asks "what learning styles does the user respond to best?", and Honcho can answer from accumulated interaction.

Мини-кейс: multi-agent engineering team

Представим workspace, где работают:

human lead;
code agent;
review agent;
docs agent;
QA agent.

Каждый peer участвует в sessions. Honcho может хранить:

что code agent знает о project conventions;
что review agent заметил о common mistakes;
что human lead предпочитает в pull requests;
какие sessions содержали важные decisions.

Observer/observed model здесь особенно полезен: review agent's view of code agent может отличаться от code agent's self-representation.

Сравнение с EverOS

Критерий	EverOS	Honcho
Главный принцип	Local-first Markdown source of truth	Peer-centric evolving representations
Source visibility	Очень высокая	Через APIs, conclusions, representations
Core entities	User/agent tracks, wiki, files	Workspace, peer, session, message
Runtime	Local memory runtime	FastAPI server + background workers
Сильный сценарий	User-owned portable memory	Social, multi-peer, stateful agents
License	Apache-2.0	AGPL-3.0

EverOS лучше, когда важны readable files and ownership. Honcho лучше, когда нужно моделировать отношения and participants.

Сравнение с Supermemory

Supermemory делает user profile and hybrid context engine. Honcho делает peer representations and conclusions.

Разница тонкая, но важная:

Supermemory: "дай профиль пользователя and relevant memories";
Honcho: "что эта система знает о peer, возможно с perspective другого peer?"

Если продукт похож на персонального assistant, Supermemory может быть проще. Если продукт похож на multiplayer AI environment, tutor, companion, group agent or social simulation, Honcho становится интереснее.

Риски и ограничения

Первый риск - asynchronous freshness. Новые messages могут не сразу отражаться в conclusions. Нужно проектировать UX and consistency expectations.

Второй риск - complexity. Postgres, pgvector, workers, migrations, LLM provider routing and auth are real infrastructure.

Третий риск - psychological inference. Peer representations may infer sensitive traits. Нужны consent, policy, data minimization and deletion.

Четвертый риск - AGPL license fit. Для некоторых commercial deployments это blocker.

Пятый риск - over-personalization. Агент может слишком сильно опираться на inferred representation, даже когда пользователь в текущей задаче хочет другой режим.

Как тестировать Honcho

Тест	Что проверяет
Workspace isolation	Данные разных workspaces не смешиваются.
Peer identity	Messages correctly attributed to source peers.
Many-to-many sessions	Session with multiple peers builds correct context.
Async freshness	Representation updates after deriver processing.
Low-latency representation	Fast endpoint suitable for prompt injection.
Conclusions quality	Derived conclusions are accurate and useful.
Search evidence	Hybrid search can support or challenge conclusions.
Queue observability	`queue_status` helps debug processing lag.
Deletion and retention	Peer/session data can be removed according to policy.

Для evaluation полезно создавать scenarios with multiple peers and conflicting evidence. Простые single-user chats не проверяют уникальную силу Honcho.

Практический rollout

Начните с одного workspace and two peers: user and assistant. Проверьте add messages, context, representation and search.

Затем добавьте третьего peer, например reviewer-agent. Проверьте, что session model handles many-to-many interactions and that peer-specific insights remain distinct.

После этого включайте self-hosting complexity: auth, workers, monitoring, queue metrics and backup. Не начинайте с полной multi-agent topology before core peer model is verified.

Антипаттерны

Первый антипаттерн - использовать Honcho как простой vector DB. Тогда вы платите complexity, но не используете peer model.

Второй антипаттерн - смешивать всех participants in one peer. Это убивает главный смысл системы.

Третий антипаттерн - игнорировать background lag. Если UX предполагает immediate memory, asynchronous reasoning нужно компенсировать representation/search strategy.

Четвертый антипаттерн - не объяснять пользователю inferred traits. Social memory without transparency can feel invasive.

Чек-лист выбора Honcho

Honcho стоит рассмотреть, если:

система включает several humans and/or AI agents;
важно моделировать participants over time;
нужны peer representations, conclusions and session context;
long-running conversations should continue indefinitely;
команда готова держать server + worker infrastructure;
нужен self-host option;
social trust and retention are product goals.

Если вы хотите simple personal memory, начните с Mem0/Supermemory. Если нужен Markdown-owned local memory, смотрите EverOS. Если нужен graph-RAG по documents, смотрите Cognee.

Источники

GitHub repository: https://github.com/plastic-labs/honcho
README: https://github.com/plastic-labs/honcho/blob/main/README.md
Documentation: https://docs.honcho.dev
Product site: https://honcho.dev
Self-hosting section: https://github.com/plastic-labs/honcho#self-hosting

Краткое резюме

Honcho показывает peer-centric approach to agent memory. Его главная единица - не документ and не user profile, а peer: человек, агент, группа, проект or идея, меняющиеся во времени.

Сильная сторона Honcho - stateful social and multi-agent systems. Он дает conclusions, representations, peer cards, session context and hybrid search, но требует более серьезной infrastructure and careful privacy design.

Вопросы для самопроверки

Чем peer отличается от user profile?
Почему sessions and peers имеют many-to-many relationship?
Что делает background deriver?
Чем conclusion отличается от representation?
Зачем нужны observer/observed peer pairs?
Какие риски возникают при psychological inference?
Когда Honcho лучше Supermemory?
Почему Honcho не стоит использовать как обычный vector DB?

Что дальше

В следующей лекции мы разберем MemSearch - исследовательский инструмент/подход к memory search, который полезен для понимания того, как оценивать retrieval over conversational memory and long-horizon questions.