feat: draft ready for review
This commit is contained in:
vintro
parent
2cb07e4df4
commit
c53ba8dd6e
|
|
@ -12,25 +12,21 @@ If you'd like to experience this methodology first-hand, try out [Honcho Chat](h
|
|||
|
||||
## Why Reasoning?
|
||||
|
||||
TODO: workshop, i think it's a bit wordy?
|
||||
Traditional RAG systems treat memory as static storage--they retrieve what was explicitly said when semantically similar queries appear. Other solutions take an opinion for you on what's important to store, whether through structured facts in databases or predefined knowledge graphs. Honcho takes a different approach: we extract all latent information by reasoning about everything, so it's there when you need it. Our job is to produce the most robust reasoning possible--it's your job as a developer to decide what's relevant for your use case.
|
||||
|
||||
Traditional RAG systems treat memory as static storage--they retrieve what was explicitly said and surface it when semantically similar queries appear. Some approaches try to store structured "facts" in relational databases or knowledge graphs, but these assume you already know what's worth storing and how to structure it. Either way, once stored, those artifacts are static. You can only get back what was put in, not what logically follows. These systems are brittle, deal poorly with contradictions and incomplete information, and miss the dynamic nature of understanding.
|
||||
|
||||
Honcho uses formal logic to power its system because we believe you need reasoning to access insights that are only accessible by *rigorously thinking* about your data. Static retrieval can't surface implicit connections, struggles when new information contradicts old data, and fails when you need to make predictions under uncertainty.
|
||||
|
||||
Formal logical reasoning is AI-native--it performs the rigorous, compute-intensive type of reasoning that humans struggle with, instantly and consistently. Honcho uses this capability to generate new insights that go beyond simple recall, transforming retrieved context into something richer and more useful.
|
||||
We extract this latent information through formal logic. Formal logical reasoning is AI-native--LLMs perform the rigorous, compute-intensive thinking that humans struggle with, instantly and consistently. This unlocks insights that are only accessible by *rigorously thinking* about your data, generating new understanding that goes beyond simple recall.
|
||||
|
||||
## Formal Logic Framework
|
||||
|
||||
Honcho's memory system is powered by custom models trained to perform three types of formal, logical reasoning: deduction, induction, and abduction. The system takes what was explicitly stated and uses them as premises to deduce conclusions based on what the model can be certain about. It then uses those conclusions as premises to identify patterns, or induce probabilistic conclusions. And it can use all of those to arrive at the simplest explanations for previous conclusions, or abductive conclusions.
|
||||
Honcho's memory system is powered by custom models trained to perform formal logical reasoning. The system extracts what was explicitly stated, draws certain conclusions from those, identifies patterns across multiple conclusions, and infers the simplest explanations for behavior.
|
||||
|
||||
Why formal logic specifically? LLMs are uniquely well-suited for this reasoning task--it's well-represented in the pretraining data. LLMs can maintain consistent reasoning across thousands of observations without cognitive fatigue or belief resistance--which is extremely hard for humans to do reliably. The outputs are also composable, meaning logical conclusions can be stored, retrieved, and combined programmatically for dynamic context assembly.
|
||||
Why formal logic specifically? LLMs are uniquely well-suited for this reasoning task--it's well-represented in the pretraining data. LLMs can maintain consistent reasoning across thousands of conclusions without cognitive fatigue or belief resistance--which is extremely hard for humans to do reliably. The outputs are also composable, meaning logical conclusions can be stored, retrieved, and combined programmatically for dynamic context assembly.
|
||||
|
||||
Here's an example of a data structure the reasoning models generate:
|
||||
|
||||
```json
|
||||
{
|
||||
"thinking": "",
|
||||
"explicit": [
|
||||
{
|
||||
"content": "premise 1"
|
||||
|
|
@ -60,9 +56,9 @@ The reasoning that Honcho does is something we're constantly iterating and impro
|
|||
|
||||
## How It Works
|
||||
|
||||
When you write messages to Honcho, they're stored immediately and enqueued for background processing. Reasoning is computationally expensive, so processing asynchronously ensures fast writes while still providing rich reasoning capabilities. Messages are stored immediately without blocking, and session-based queues maintain chronological consistency so reasoning tasks affecting the same peer representation are always processed in order.
|
||||
When you write messages to Honcho, they're stored immediately and enqueued for background processing. Reasoning asynchronously ensures fast writes while still providing rich reasoning capabilities. Messages are stored immediately without blocking, and session-based queues maintain chronological consistency so reasoning tasks affecting the same peer representation are always processed in order.
|
||||
|
||||
The reasoning models extract explicit premises from message content, draw deductive conclusions from those premises, and use those conclusions to scaffold higher-order reasoning. These artifacts--observations, conclusions, summaries, peer cards--are stored as part of peer representations and indexed in vector collections for retrieval.
|
||||
The reasoning outputs--conclusions, summaries, peer cards--are stored as part of peer representations, indexed in vector collections for retrieval.
|
||||
|
||||
|
||||
|
||||
|
|
@ -70,9 +66,9 @@ The diagram above shows how agents write messages to Honcho, which triggers reas
|
|||
|
||||
## Balances & Design Choices
|
||||
|
||||
Off-the-shelf LLMs can perform reasoning, but they aren't optimized for it. Honcho uses custom models trained specifically for logical rigor (following formal reasoning rules rather than plausible-sounding text), structured output (consistent JSON schema with premises and conclusions), and efficiency (smaller, faster models tuned for this specific task). This allows Honcho to reason more reliably and at lower cost than general-purpose frontier LLMs.
|
||||
Off-the-shelf LLMs can perform formal logical reasoning, but they aren't optimized for it. Honcho uses custom models trained specifically for logical rigor (following formal reasoning rules rather than plausible-sounding text), structured output (consistent JSON schema with premises and conclusions), and efficiency (smaller, faster models tuned for this specific task). This allows Honcho to reason more reliably and at lower cost than general-purpose frontier LLMs.
|
||||
|
||||
The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, background processing means reasoning doesn't block user interactions, and structured conclusions are more token-efficient than raw conversation history. Not every message requires full reasoning--we batch where appropriate to optimize update frequency.
|
||||
The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, scaffolded conclusions are more token-efficient than raw conversation history, and we batch where appropriate to optimize update frequency.
|
||||
|
||||
Honcho's reasoning capabilities are actively being improved. Current areas of development include enhanced inductive and abductive reasoning, multi-hop and temporal reasoning, and expanded file types and modalities. The system is designed to be extensible--new reasoning capabilities can be added without breaking existing functionality.
|
||||
|
||||
|
|
@ -82,6 +78,8 @@ If you find that the data you're uploading to Honcho isn't being reasoned over t
|
|||
|
||||
## Next Steps
|
||||
|
||||
Without exhaustive reasoning, you're stuck with surface-level retrieval or someone else's opinion on what matters. You can't effectively simulate statefulness if you're not reasoning about everything in the present--coherence plummets, trust falls, and users churn. Don't leave key information on the table. Use Honcho to give your agents the context they need to reconstruct the past as comprehensively as possible and maintain coherence--for your use case.
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
|
||||
Sign up for the Honcho platform and start building
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ A peer representation is made up of several types of artifacts that Honcho gener
|
|||
|
||||
**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.
|
||||
|
||||
These enable continuous improvement. Each new message refines conclusions, updates summaries, and keeps peer cards current—building a more accurate representation over time.
|
||||
|
||||
|
||||
## Observation & Perspective-Taking
|
||||
|
||||
|
|
@ -27,7 +29,7 @@ There are two observation modes controlled by [configuration](/v2/documentation/
|
|||
|
||||
**Honcho observing peers** (`observe_me`): When enabled (default), Honcho forms a representation of the peer based on all messages they've sent across all sessions. This is Honcho's understanding of that peer, built from everything they've said and done in your system. Set `observe_me: false` if you don't want Honcho to reason about that peer at all.
|
||||
|
||||
**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 Bob are in a session together and Bob has `observe_others: true`, Bob will form a representation of Alice based solely on what Alice said in sessions Bob participated in. Bob's representation of Alice will be completely different from Carol's representation of Alice if they've observed different interactions.
|
||||
**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 Bob are in a session together and Alice has `observe_others: true`, Alice will form a representation of Bob based solely on what Bob said in sessions Alice participated in. Alice's representation of Bob will be completely different from Charlie's representation of Bob if they've observed different interactions.
|
||||
|
||||
In the diagram below, assume `observe_me` isn't turned off (again, default behavior) and `observe_others` is turned on for both peers in a session that contains the peers Alice and Bob.
|
||||
|
||||
|
|
@ -35,7 +37,7 @@ In the diagram below, assume `observe_me` isn't turned off (again, default behav
|
|||
|
||||
The shared session that Alice and Bob have informs their respective representations of each other. Alice has a small set of conclusions that pertain to Bob, and Bob has a small set of conclusions that pertain to Alice. Honcho can observe the totality of each peer's interactions, forming representations of the peers themselves, and enable peers to store conclusions about peers they interact with based only on what they witness in shared sessions.
|
||||
|
||||
Why would you want peers observing others? So you can simulate stateful *perspectives*. If Bob participates in sessions 1 and 2 with Alice, while Carol only participates in session 3, Bob's representation of Alice will be built from sessions 1 and 2, while Carol's representation will only include what happened in session 3. This information segmentation based on what each agent observed is critical for accurately segmenting statefulness in multi-agent scenarios.
|
||||
Why would you want peers observing others? So you can simulate stateful *perspectives*. If Bob participates with Alice in sessions 1 and 2, while Charlie participates with Alice in session 3, Bob's representation of Alice will be built from sessions 1 and 2, while Charlie's representation will only include what happened in session 3. Bob can reference shared history, inside jokes, or past conflicts that Charlie knows nothing about. Without perspective-based segmentation, all agents are omniscient--the simulation breaks down, trust falls apart, and users churn.
|
||||
|
||||
|
||||
## Why Representations Work
|
||||
|
|
|
|||
|
|
@ -42,26 +42,26 @@ These are stored as separate (observer, observed) pairs in Honcho's internal col
|
|||
| Observer | Observed | What This Represents |
|
||||
|----------|----------|---------------------|
|
||||
| alice | alice | Honcho's representation of Alice (across all sessions) |
|
||||
| bob | alice | Bob's representation of Alice (from sessions Bob participated in) |
|
||||
| carol | alice | Carol's representation of Alice (from sessions Carol participated in) |
|
||||
| alice | bob | Alice's representation of Bob (from sessions Alice participated in) |
|
||||
| alice | charlie | Alice's representation of Charlie (from sessions Alice participated in) |
|
||||
|
||||
### Information Segmentation
|
||||
|
||||
This enables sophisticated scenarios where different agents have different knowledge based on what they've actually witnessed.
|
||||
|
||||
**Example**: Alice tells different things to Bob and Carol.
|
||||
**Example**: Bob and Charlie tell different things to Alice in separate sessions.
|
||||
|
||||
```
|
||||
Session 1 (Alice + Bob):
|
||||
Alice → "I had pancakes for breakfast."
|
||||
Bob → "I had pancakes for breakfast."
|
||||
|
||||
Session 2 (Alice + Carol):
|
||||
Alice → "I didn't eat breakfast. I lied to Bob."
|
||||
Session 2 (Alice + Charlie):
|
||||
Charlie → "I had pancakes for breakfast. Bob is lying about his breakfast."
|
||||
```
|
||||
|
||||
With `observe_others=true` enabled:
|
||||
- **Bob's representation of Alice** only includes Session 1 (he believes she had pancakes)
|
||||
- **Carol's representation of Alice** only includes Session 2 (she knows Alice lied)
|
||||
With `observe_others=true` enabled on Alice:
|
||||
- **Alice's representation of Bob** only includes Session 1 (she heard Bob say he had pancakes)
|
||||
- **Alice's representation of Charlie** only includes Session 2 (she heard Charlie's claim about Bob lying)
|
||||
- **Honcho's representation of Alice** reasons over both sessions
|
||||
|
||||
|
||||
|
|
@ -73,8 +73,8 @@ The `target` parameter controls which representation you retrieve:
|
|||
| Query | Returns |
|
||||
|-------|---------|
|
||||
| `working_rep("alice")` | Conclusions from Honcho's representation of Alice (across all sessions) |
|
||||
| `working_rep("bob", target="alice")` | Conclusions from Bob's representation of Alice (from sessions Bob participated in) |
|
||||
| `working_rep("carol", target="alice")` | Conclusions from Carol's representation of Alice (from sessions Carol participated in) |
|
||||
| `working_rep("alice", target="bob")` | Conclusions from Alice's representation of Bob (from sessions Alice participated in) |
|
||||
| `working_rep("alice", target="charlie")` | Conclusions from Alice's representation of Charlie (from sessions Alice participated in) |
|
||||
|
||||
### Code Examples
|
||||
|
||||
|
|
@ -87,33 +87,33 @@ session = honcho.session("game-session")
|
|||
|
||||
alice = honcho.peer("alice")
|
||||
bob = honcho.peer("bob")
|
||||
carol = honcho.peer("carol")
|
||||
charlie = honcho.peer("charlie")
|
||||
|
||||
# Add peers to session
|
||||
session.add_peers([alice, bob, carol])
|
||||
session.add_peers([alice, bob, charlie])
|
||||
|
||||
# Enable Bob and Carol to form representations of others
|
||||
session.set_peer_config(bob, SessionPeerConfig(observe_others=True))
|
||||
session.set_peer_config(carol, SessionPeerConfig(observe_others=True))
|
||||
# Enable Alice to form representations of others
|
||||
session.set_peer_config(alice, SessionPeerConfig(observe_others=True))
|
||||
|
||||
# Add messages
|
||||
session.add_messages([
|
||||
alice.message("I had pancakes for breakfast.")
|
||||
bob.message("I had pancakes for breakfast."),
|
||||
charlie.message("I prefer waffles.")
|
||||
])
|
||||
|
||||
# Different sessions with different participants
|
||||
session2 = honcho.session("game-session-2")
|
||||
session2.add_peers([alice, carol])
|
||||
session2.set_peer_config(carol, SessionPeerConfig(observe_others=True))
|
||||
session2.add_peers([alice, charlie])
|
||||
session2.set_peer_config(alice, SessionPeerConfig(observe_others=True))
|
||||
|
||||
session2.add_messages([
|
||||
alice.message("I didn't eat breakfast. I lied to Bob.")
|
||||
charlie.message("I didn't have breakfast. I lied to Bob.")
|
||||
])
|
||||
|
||||
# Retrieve conclusions from different perspectives
|
||||
honcho_view = session.working_rep("alice") # Across all sessions
|
||||
bob_view = session.working_rep("bob", target="alice") # From Bob's sessions
|
||||
carol_view = session2.working_rep("carol", target="alice") # From Carol's sessions
|
||||
bob_view = session.working_rep("alice", target="bob") # Alice's view of Bob
|
||||
charlie_view = session2.working_rep("alice", target="charlie") # Alice's view of Charlie
|
||||
```
|
||||
|
||||
```typescript TypeScript
|
||||
|
|
@ -124,29 +124,29 @@ const session = await honcho.session("game-session");
|
|||
|
||||
const alice = await honcho.peer("alice");
|
||||
const bob = await honcho.peer("bob");
|
||||
const carol = await honcho.peer("carol");
|
||||
const charlie = await honcho.peer("charlie");
|
||||
|
||||
await session.addPeers([alice, bob, carol]);
|
||||
await session.addPeers([alice, bob, charlie]);
|
||||
|
||||
await session.setPeerConfig(bob, { observe_others: true });
|
||||
await session.setPeerConfig(carol, { observe_others: true });
|
||||
await session.setPeerConfig(alice, { observe_others: true });
|
||||
|
||||
await session.addMessages([
|
||||
alice.message("I had pancakes for breakfast.")
|
||||
bob.message("I had pancakes for breakfast."),
|
||||
charlie.message("I prefer waffles.")
|
||||
]);
|
||||
|
||||
const session2 = await honcho.session("game-session-2");
|
||||
await session2.addPeers([alice, carol]);
|
||||
await session2.setPeerConfig(carol, { observe_others: true });
|
||||
await session2.addPeers([alice, charlie]);
|
||||
await session2.setPeerConfig(alice, { observe_others: true });
|
||||
|
||||
await session2.addMessages([
|
||||
alice.message("I didn't eat breakfast. I lied to Bob.")
|
||||
charlie.message("I didn't have breakfast. I lied to Bob.")
|
||||
]);
|
||||
|
||||
// Retrieve conclusions from different perspectives
|
||||
const honchoView = await session.workingRep("alice"); // Across all sessions
|
||||
const bobView = await session.workingRep("bob", { target: "alice" }); // From Bob's sessions
|
||||
const carolView = await session2.workingRep("carol", { target: "alice" }); // From Carol's sessions
|
||||
const bobView = await session.workingRep("alice", { target: "bob" }); // Alice's view of Bob
|
||||
const charlieView = await session2.workingRep("alice", { target: "charlie" }); // Alice's view of Charlie
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
|
|
@ -158,29 +158,29 @@ The `target` parameter also works with the chat endpoint:
|
|||
```python Python
|
||||
# Query using conclusions from Honcho's representation (across all sessions)
|
||||
honcho_answer = alice.chat(
|
||||
"What did Alice say about breakfast?",
|
||||
"What did Bob say about breakfast?",
|
||||
session_id=session.id
|
||||
)
|
||||
|
||||
# Query using conclusions from Bob's representation of Alice (from Bob's sessions only)
|
||||
bob_answer = bob.chat(
|
||||
"What did Alice say about breakfast?",
|
||||
# Query using conclusions from Alice's representation of Bob (from Alice's sessions only)
|
||||
alice_answer = alice.chat(
|
||||
"What did Bob say about breakfast?",
|
||||
session_id=session.id,
|
||||
target="alice"
|
||||
target="bob"
|
||||
)
|
||||
```
|
||||
|
||||
```typescript TypeScript
|
||||
// Query using conclusions from Honcho's representation (across all sessions)
|
||||
const honchoAnswer = await alice.chat(
|
||||
"What did Alice say about breakfast?",
|
||||
"What did Bob say about breakfast?",
|
||||
{ sessionId: session.id }
|
||||
);
|
||||
|
||||
// Query using conclusions from Bob's representation of Alice (from Bob's sessions only)
|
||||
const bobAnswer = await bob.chat(
|
||||
"What did Alice say about breakfast?",
|
||||
{ sessionId: session.id, target: "alice" }
|
||||
// Query using conclusions from Alice's representation of Bob (from Alice's sessions only)
|
||||
const aliceAnswer = await alice.chat(
|
||||
"What did Bob say about breakfast?",
|
||||
{ sessionId: session.id, target: "bob" }
|
||||
);
|
||||
```
|
||||
</CodeGroup>
|
||||
|
|
@ -236,10 +236,10 @@ Both `working_rep()` and `chat()` support semantic filtering to retrieve a subse
|
|||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
# Retrieve conclusions about billing from Bob's representation of Alice
|
||||
bob_view_billing = session.working_rep(
|
||||
"bob",
|
||||
target="alice",
|
||||
# Retrieve conclusions about billing from Alice's representation of Bob
|
||||
alice_view_billing = session.working_rep(
|
||||
"alice",
|
||||
target="bob",
|
||||
search_query="billing issues",
|
||||
search_top_k=10,
|
||||
include_most_derived=True
|
||||
|
|
@ -247,8 +247,8 @@ bob_view_billing = session.working_rep(
|
|||
```
|
||||
|
||||
```typescript TypeScript
|
||||
const bobViewBilling = await session.workingRep("bob", {
|
||||
target: "alice",
|
||||
const aliceViewBilling = await session.workingRep("alice", {
|
||||
target: "bob",
|
||||
searchQuery: "billing issues",
|
||||
searchTopK: 10,
|
||||
includeMostDerived: true
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ icon: "brain"
|
|||
sidebarTitle: "Overview"
|
||||
---
|
||||
|
||||
Honcho is an open source memory library with a managed service for building stateful agents. Use it with any model, framework, or architecture. You can represent any kind of entity as a stateful agent--users, AIs, groups of users, and more. Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
|
||||
Honcho is an open source memory library with a managed service for building stateful agents. Use it with any model, framework, or architecture. It enables agents to build and maintain state about any entity--users, agents, groups, ideas, and more. And because it's a continual learning system, it understands entities that change over time. Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
|
||||
|
|
@ -19,20 +19,25 @@ Honcho is an open source memory library with a managed service for building stat
|
|||
Honcho is a memory system that reasons. Read more on the approach [here](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning).
|
||||
</Note>
|
||||
|
||||
## What Can I Use Honcho For?
|
||||
## Why Use Honcho?
|
||||
|
||||
Honcho streamlines the agent building process by offering elegant, flexible primitives for managing context. It also reasons over that context to give developers access to far richer insights only accessible through reasoning. Take the following scenario:
|
||||
Honcho streamlines the agent building process by offering elegant, flexible primitives for managing context. It also reasons over that context to give developers access to far richer insights only accessible through reasoning.
|
||||
|
||||
- You find a use case for LLMs that you want to build an application or agent around
|
||||
- It performs well but fails to retain state on the task, customers, or itself over time
|
||||
- You laboriously engineer a RAG solution that seems to help
|
||||
- Then a cycle like this begins...
|
||||
- Reports of edge cases, erroneous behavior, and other unpredictable problems that stem from context
|
||||
- You launch into an evals rabbithole and build internal benchmarks
|
||||
- Re-engineer your entire RAG solution
|
||||
Take the following scenario:
|
||||
|
||||
- You find a use case for LLMs and build an agent around it
|
||||
- It works well initially but can't maintain context across sessions
|
||||
- You spend weeks engineering a RAG solution that seems to help
|
||||
- Then the cycle begins...
|
||||
- Users report the agent forgetting things, contradicting itself, or losing context mid-session
|
||||
- You build evals to quantify the problem
|
||||
- You re-engineer your entire RAG pipeline with better chunking, embeddings, retrieval strategies
|
||||
- The problems shift but don't disappear
|
||||
- Repeat
|
||||
|
||||
All the while usage dwindles, customers churn, and motivation to solve the problem wanes. Break free from this cycle. Honcho is a general solution to context engineering, memory, and statefulness.
|
||||
Eventually you realize the issue isn't engineering—-it's that you're not extracting all the latent information from your data. You need to reason exhaustively, handle contradictions, track patterns over time, and maintain coherent state. In other words, you'd need to build Honcho.
|
||||
|
||||
Break free from this cycle. Honcho is a general solution to context engineering, memory, and statefulness.
|
||||
|
||||
## How Honcho Works
|
||||
|
||||
|
|
@ -54,9 +59,9 @@ Honcho has four storage primitives that work together:
|
|||
```
|
||||
|
||||
- **Workspaces** - Top-level containers that isolate different applications or environments
|
||||
- **Peers** - Any entity that persists over time (users, agents, objects, and more)
|
||||
- **Peers** - Any entity that persists but changes over time (users, agents, objects, and more)
|
||||
- **Sessions** - Interaction threads between peers with temporal boundaries
|
||||
- **Messages** - Units of interaction that trigger reasoning
|
||||
- **Messages** - Units of data that trigger reasoning (conversations, events, activity, documents, and more)
|
||||
|
||||
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) to generate conclusions 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.
|
||||
|
||||
|
|
@ -66,11 +71,9 @@ The diagram above shows the flow: agents write messages to Honcho, which trigger
|
|||
|
||||
## Why Reasoning?
|
||||
|
||||
TODO: Workshop this
|
||||
Traditional RAG systems retrieve what was explicitly said, but they miss what matters most—the insights only accessible by *rigorously thinking* about your data. Without reasoning, you're leaving latent information on the table. Static retrieval can't surface implicit connections, struggles when new information contradicts old data, and fails when you need to make predictions under uncertainty.
|
||||
|
||||
Traditional RAG systems retrieve what was explicitly said, but they miss things that are only accessible by *rigorously thinking* about your data. Static retrieval can't surface implicit connections, struggles when new information contradicts old data, and fails when you need to make predictions under uncertainty.
|
||||
|
||||
Honcho uses formal logic to generate new insights by combining premises. This reasoning is AI-native--it performs the rigorous, compute-intensive type of reasoning that humans struggle with, instantly and consistently. The result is memory that goes beyond simple recall to provide truly contextual understanding.
|
||||
Honcho uses formal logic to extract all that latent information. This reasoning is AI-native—it performs the rigorous, compute-intensive thinking that humans struggle with, instantly and consistently. The result is memory that goes beyond simple RAG recall to provide exhaustive context for statefulness.
|
||||
|
||||
## Get Started
|
||||
|
||||
|
|
|
|||
|
|
@ -5,22 +5,19 @@ description: "Universal starter prompt for building with Honcho"
|
|||
sidebarTitle: 'Vibecoding Setup'
|
||||
---
|
||||
|
||||
These docs are designed to be easily consumable for LLMs. Each page has a button
|
||||
the lets you copy the page as Markdown or paste directly into ChatGPT or Claude.
|
||||
These docs are designed to be easily consumable by LLMs. Each page has a button that lets you copy the page as Markdown or paste directly into ChatGPT or Claude.
|
||||
|
||||
Additionally, we follow the llms.txt standard. There are both an llms.txt and
|
||||
llms-full.txt available.
|
||||
We follow the llms.txt standard. There are both an llms.txt and llms-full.txt available:
|
||||
|
||||
- [llms.txt](/llms.txt)
|
||||
- [llms-full.txt](/llms-full.txt)
|
||||
|
||||
Additionally, we provide a starter prompt to paste into a coding assistant to
|
||||
quickly get started building with Honcho.
|
||||
We also provide a starter prompt to paste into a coding assistant to quickly get started building with Honcho.
|
||||
|
||||
## 🚀 Universal Starter Prompt
|
||||
## Universal Starter Prompt
|
||||
|
||||
```
|
||||
I want to start building with Honcho - a memory and personalization platform for AI applications.
|
||||
I want to start building with Honcho - an open source memory library for building stateful agents.
|
||||
|
||||
## Honcho Resources
|
||||
|
||||
|
|
@ -28,7 +25,7 @@ I want to start building with Honcho - a memory and personalization platform for
|
|||
- Main docs: https://docs.honcho.dev
|
||||
- API Reference: https://docs.honcho.dev/v2/api-reference/introduction
|
||||
- Quickstart: https://docs.honcho.dev/v2/documentation/introduction/quickstart
|
||||
- Architecture: https://docs.honcho.dev/v2/documentation/reference/architecture
|
||||
- Architecture: https://docs.honcho.dev/v2/documentation/core-concepts/architecture
|
||||
|
||||
**Code & Examples:**
|
||||
- Core repo: https://github.com/plastic-labs/honcho
|
||||
|
|
@ -38,27 +35,25 @@ I want to start building with Honcho - a memory and personalization platform for
|
|||
- Telegram bot example: https://github.com/plastic-labs/telegram-python-starter
|
||||
|
||||
**What Honcho Does:**
|
||||
Honcho provides persistent memory and personalization for AI apps. It automatically:
|
||||
- Stores conversation history across sessions
|
||||
- Learns facts about users from conversations
|
||||
- Builds user representations for personalized responses
|
||||
- Manages multi-user sessions with theory of mind
|
||||
- Provides context injection for any LLM
|
||||
Honcho is an open source memory library with a managed service for building stateful agents. It enables agents to build and maintain state about any entity--users, agents, groups, ideas, and more. Because it's a continual learning system, it understands entities that change over time.
|
||||
|
||||
When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical reasoning to generate conclusions about each peer. These conclusions are stored as representations that you can query to provide rich context for your agents.
|
||||
|
||||
**Architecture Overview:**
|
||||
- Core primitives: Workspaces contain Peers (users/agents) and Sessions (conversations)
|
||||
- Peers can observe other peers in sessions (configurable with observe_me_observe_others)
|
||||
- Background deriver processes messages to extract facts and update representations
|
||||
- Dialectic API provides personalized responses based on learned context
|
||||
- Core primitives: Workspaces contain Peers (any entity that persists but changes) and Sessions (interaction threads between peers)
|
||||
- Peers can observe other peers in sessions (configurable with observe_me and observe_others)
|
||||
- Background reasoning processes messages to extract premises, draw conclusions, and build representations
|
||||
- Representations enable continuous improvement as new messages refine existing conclusions and scaffold new ones over time
|
||||
- Chat endpoint provides personalized responses based on learned context
|
||||
- Supports any LLM (OpenAI, Anthropic, open source)
|
||||
- Can use demo server or self-host
|
||||
- Can use managed service or self-host
|
||||
|
||||
Please assess the resources above and ask me relevant questions to help build a well-structured application using Honcho. Consider asking about:
|
||||
- What I'm trying to build
|
||||
- My technical preferences and stack
|
||||
- Whether I want to use the demo server or self-host
|
||||
- Whether I want to use the managed service or self-host
|
||||
- My experience level with the technologies involved
|
||||
- Specific features I need (multi-user, voice, web UI, etc.)
|
||||
- Specific features I need (multi-peer sessions, perspective-taking, streaming, etc.)
|
||||
|
||||
Once you understand my needs, help me create a working implementation with proper memory persistence.
|
||||
Once you understand my needs, help me create a working implementation with proper memory and statefulness.
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue