fix: various tweaks

This commit is contained in:
vintro 2025-12-06 14:44:22 -05:00
parent ba54e21d70
commit a4f036ba6d
No known key found for this signature in database
5 changed files with 7 additions and 19 deletions

BIN
docs/images/alice-bob.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 164 KiB

View File

@ -83,7 +83,7 @@ Understanding how data moves through Honcho helps clarify the architecture.
When you create messages, they're immediately written to PostgreSQL and reasoning tasks are added to background queues. Background workers then generate logic, summaries, and new insights to improve representations. These conclusions and insights get stored in vector collections for retrieval. This async approach ensures fast writes while still providing rich reasoning capabilities.
When you need context from Honcho, you query through the "Chat" endpoint or "Get Context" endpoint. Honcho retrieves relevant observations and conclusions from vector storage along with recent messages, then assembles everything into coherent context ready to inject into agent prompts.
When you need context from Honcho, you query through the "Chat" endpoint or "Get Context" endpoint. Honcho retrieves relevant conclusions from vector storage along with recent messages, then assembles everything into coherent context ready to inject into agent prompts.
![Honcho Architecture](/images/architecture.png)

View File

@ -6,21 +6,19 @@ sidebarTitle: "Representations"
A peer representation is the collection of reasoning Honcho has done about a peer over time. It's not a static profile or a snapshot--it's the accumulated output of continuous reasoning about every message that's been written to the peer. Representations evolve dynamically as new messages come in, with Honcho reasoning about them in the context of existing conclusions, reconciling contradictions and refining understanding.
When you write messages to Honcho, the reasoning models extract premises, draw conclusions, and generate insights. All of that reasoning--observations, conclusions, summaries, peer cards--gets stored as the peer's representation. Think of it as Honcho's understanding of who that peer is, what they care about, and how they behave, built through formal logic rather than simple storage.
When you write messages to Honcho, the reasoning models extract premises, draw conclusions, and generate insights. All of that reasoning gets stored as the peer's representation. Think of it as Honcho's understanding of who that peer is, what they care about, and how they behave, built through formal logic rather than simple storage.
## What's in a Representation?
A peer representation is made up of several types of artifacts that Honcho generates through reasoning:
**Observations** are explicit premises extracted directly from messages. If a user says "I'm saving for a house," that's an observation. These serve as the foundation for further reasoning.
**Conclusions** are insights derived through formal logic. Deductive conclusions are things Honcho can be certain about based on the observations. Inductive conclusions identify patterns across multiple messages. Abductive conclusions infer the simplest explanations for observed behavior. For example, if a user frequently mentions work deadlines and rarely mentions hobbies, Honcho might inductively conclude they're time-constrained or career-focused.
**Conclusions** are insights derived through formal logic. Deductive conclusions are things Honcho can be certain about based on the premises. Inductive conclusions identify patterns across multiple messages. Abductive conclusions infer the simplest explanations for observed behavior. For example, if a user frequently mentions work deadlines and rarely mentions hobbies, Honcho might inductively conclude they're time-constrained or career-focused.
**Summaries** capture the essence of sessions. Short summaries are generated every 20 messages by default, and long summaries every 60 messages. These help compress conversation history into dense, queryable context.
**Peer cards** contain key biographical information. They essentially cache the most basic information about a peer (name, occupation, interests) to ensure the model never loses its grounding.
The reasoning flows from observations to conclusions to higher-order artifacts. Each layer builds on what came before, creating a rich, queryable representation.
TODO: workshop this--The reasoning flows from premises to conclusions to higher-order artifacts. Each layer builds on what came before, creating a rich, queryable representation.
<Note>
For details on how reasoning works (deduction, induction, abduction), see the [Reasoning](/v2/documentation/core-concepts/reasoning) page.
@ -36,7 +34,7 @@ There are two observation modes controlled by configuration:
**Peers observing others** (`observe_others`): When enabled at the session level, a peer will form representations of other peers in that session based only on messages they've observed. If Alice and Opus are in a session together and Opus has `observe_others: true`, Opus will form a representation of Alice based solely on what Alice said in sessions Opus participated in. Opus's representation of Alice will be completely different from Carol's representation of Alice if they've observed different interactions.
![](/images/perspectives.jpeg)
![](/images/alice-bob.png)
The diagram above shows observation in practice. Honcho can observe each peer (forming representations based on everything they say), and individual peers can observe others (forming representations based only on what they witness in shared sessions).

View File

@ -7,16 +7,6 @@ icon: "message-question"
The Chat endpoint (`peer.chat()`) is the natural language interface to Honcho's reasoning. Instead of manually retrieving observations or conclusions, your LLM can ask questions and get synthesized answers based on all the reasoning Honcho has done about a peer. Think of it as agent-to-agent communication.
## How It Works
Honcho builds a [*representation*](/v2/documentation/core-concepts/representation)for each peer--a collection of conclusions drawn from continuous reasoning over context. The most flexible way to query representations is through the `chat()` method. Some examples:
- "What is the user's preferred communication style?"
- "Has the user mentioned any dietary restrictions?"
- "What tasks does the user struggle with?"
Honcho searches the peer's representation, retrieves relevant conclusions, and synthesizes a natural language answer. It acts like a detective reasoning over evidence to make a case--your LLM asks the question, Honcho composes an answer from its conclusions.
## Basic Usage
The simplest way to use the Dialectic endpoint is to ask a question and get a text response:

View File

@ -43,11 +43,11 @@ Honcho has four core primitives that work together:
- **Sessions** - Interaction threads between peers with temporal boundaries
- **Messages** - Units of interaction that trigger reasoning
When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical [*reasoning*](/v2/documentation/core-concepts/reasoning) (deduction, induction, abduction) to generate insights about each peer. These insights--observations, conclusions, summaries--are stored as [*representations*](/v2/documentation/core-concepts/representation) that you can query to provide rich context for your agents.
When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical [*reasoning*](/v2/documentation/core-concepts/reasoning) (deduction, induction, abduction) to generate insights about each peer. These conclusions are stored as [*representations*](/v2/documentation/core-concepts/representation) that you can query to provide rich context for your agents.
![Honcho Architecture](/images/architecture.png)
The diagram above shows the flow: agents write messages to Honcho, which triggers reasoning that updates what's stored in representations. Develoers (or agents) can then query to get additional context for their next response.
The diagram above shows the flow: agents write messages to Honcho, which triggers reasoning that updates what's stored in representations. Developers (or agents) can then query to get additional context for their next response.
## Why Reasoning?