* chore: Update versioning for release * fix: remove db creation at start and sync migrations and models * fix: Checkpoint changing metamessage schema * chore: linter fixes * fix: session cloning working * Hybrid long-term memory (#92) * Add TOM method switching * Add system prompt and note on format * Add persistence tweaks * Specify format for each section of user representation * Parse XML tags before saving representation metamessage * Clean up * Use Claude 3.5 Haiku and refine prompt * Simplify message processing * chore: update token limit on dialectic and model for deriver * Add embedding-based long-term fact retrieval * Fix bug preventing new documents from being created * Use multiple queries + tweak prompt * Fix collection name bug + add duplicate removal * First implementation of on-demand user rep generation * WIP debug on-demand user rep changes * Fixed representations not being stored & deriver issue * Some speed improvements * Play with number of facts / queries * WIP prompt caching for Claude * WIP fix anthropic caching * Anthropic prompt caching working but messages too short * Use Cerebras for small inferences * Make dialectic responses 1000 tokens max * Make user representation generation model a constant * Use llama 3.1 8b for query generation * Update env template * Add crud.get_or_create_protected_collection * rabbit comments * Fix linter issues * Add Cerebras to stream router method * Better handling of default-empty string args * Change prints to debug logs * Add error handling to TOM inference * Handle missing/empty client in model responses * Handle no messages case in get_chat_history * Fix indent * Add error handling to single_prompt methods * Fix get_or_create_user_protected_collection * Simplify openAI-compatible model client instantiation * Remove health endpoint * Remove LocalEmbeddingStore * Change prints to debug logs * Change sentry track * Code review changes * Add README to ToM module * Switch to Groq * Fix inconsistent openai compatible provider list in stream() * Update env template to include Groq variables * Add model_client tests * fix: Fix unit tests --------- Co-authored-by: Vineeth Voruganti <13438633+VVoruganti@users.noreply.github.com> * add scoped API keys (#91) * add AUTH_JWT_SECRET and ADMIN_KEY, use in security middleware (TODO granular keys) * WIP: convert all API paths to use scoped keys * add basic unit tests for API keys, ruff formatting * MVP of route using JWT for payload * add get_user_from_token * add key table to postgres, use it to enable key revocation * add key revocation pt 2 -- fix order of param checks * finish convenience routes that assume params from JWT * add tests for key API * get_keys * add secrets utility script, add key rotation, fill out tests * add tiny cache as PoC * nits, validations, etc * only create keys table migration if necessary * fix keys tests to always use auth * tiny fix to make custom DATABASE_SCHEMA work * review: add better docs, fix security issue with cache, clear db on rotation, and more * remove rotation * remove key database entirely * Add `/all` path to get all apps (#94) * add `/all` path for apps * assert vector extension installed (need this for groudon) * review --------- Co-authored-by: Vineeth Voruganti <13438633+VVoruganti@users.noreply.github.com> * add scoped API keys (#91) * add AUTH_JWT_SECRET and ADMIN_KEY, use in security middleware (TODO granular keys) * WIP: convert all API paths to use scoped keys * add basic unit tests for API keys, ruff formatting * MVP of route using JWT for payload * add get_user_from_token * add key table to postgres, use it to enable key revocation * add key revocation pt 2 -- fix order of param checks * finish convenience routes that assume params from JWT * add tests for key API * get_keys * add secrets utility script, add key rotation, fill out tests * add tiny cache as PoC * nits, validations, etc * only create keys table migration if necessary * fix keys tests to always use auth * tiny fix to make custom DATABASE_SCHEMA work * review: add better docs, fix security issue with cache, clear db on rotation, and more * remove rotation * remove key database entirely * Add `/all` path to get all apps (#94) * add `/all` path for apps * assert vector extension installed (need this for groudon) * review --------- Co-authored-by: Vineeth Voruganti <13438633+VVoruganti@users.noreply.github.com> * chore: README and CHANGELOG updates * add JWT expiry * fix: Consolidate get methods with JWT token resolution * chore: Add Annotation to Path, Query, and Body params * chore: run ruff formatter * chore: nits & add one exhaustive test of a query route * fix: undo change to fly.toml * fix: Langfuse tracing * Consolidate Get Methods (#96) * fix: Consolidate get methods with JWT token resolution * chore: Add Annotation to Path, Query, and Body params * chore: run ruff formatter * chore: nits & add one exhaustive test of a query route * fix: undo change to fly.toml --------- Co-authored-by: dr-frmr <docterformer@protonmail.com> * fix: dev-667 fix streaming endpoint * fix: Anthropic Langfuse Tracing * fix: add scripts folder to dockerfile * fix: Remove redundant fields from pydantic schemas * fix: Add deeper protection on reserved collection * fix: Consolidate chat and stream methods * docs: Update Mintlify API Reference and Changelog * remove langchain guide, update architecture diagram * honcho mcp server * chore: Update .env template * update discord, temporarily remove other guides * Limit dialectic & deriver context usage with two-scale progressive summarization (#97) * WIP two tiered summaries * Move to process_item * Save user rep metamessage even if no message_id * Change number of messages per short summary * Fix broken mock * Remove prints * chore: fix test --------- Co-authored-by: Vineeth Voruganti <13438633+VVoruganti@users.noreply.github.com> * feat: Add Gemini Support, link facts to message, use 8b for dialectic fact queries * chore: Styling * chore: coderabbit nitpicks * keep dialectic guide * Add streaming guide * Remove TODO from dialectic guide * Fix JS snippets that referred to honcho singleton as client * Add App explanation to architecture page --------- Co-authored-by: Dani Balcells <18307962+danibalcells@users.noreply.github.com> Co-authored-by: doria <93405247+dr-frmr@users.noreply.github.com> Co-authored-by: dr-frmr <docterformer@protonmail.com> Co-authored-by: vintro <vince@plasticlabs.ai> Co-authored-by: Daniel Balcells <dbalcells@gmail.com> |
||
|---|---|---|
| .github | ||
| .vscode | ||
| docs | ||
| migrations | ||
| scripts | ||
| src | ||
| tests | ||
| .dockerignore | ||
| .env.template | ||
| .gitignore | ||
| .python-version | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| README.md | ||
| alembic.ini | ||
| docker-compose.yml.example | ||
| fly.toml | ||
| init.sql | ||
| pyproject.toml | ||
| uv.lock | ||
README.md
🫡 Honcho
Honcho is a platform for making AI agents and LLM powered applications that are personalized to their end users. It leverages the inherent theory-of-mind capabilities of LLMs to cohere to user psychology over time.
Read about the project here.
Read the user documentation here
Table of Contents
Project Structure
The Honcho project is split between several repositories with this one hosting the core service logic. This is implemented as a FastAPI server/API to store data about an application's state.
There are also client-sdks that are created using Stainless. Currently, there is a Python and TypeScript/JavaScript SDK available.
Examples on how to use the SDK are located within each SDK repository. There is also SDK example usage available in the API Reference along with various guides.
Usage
Currently, there is a demo server of Honcho running at https://demo.honcho.dev. This server is not production ready and does not have an reliability guarantees. It is purely there for evaluation purposes.
A private beta for a tenant isolated production ready version of Honcho is currently underway. If interested fill out this typeform and the Plastic Labs team will reach out to onboard users.
Additionally, Honcho can be self-hosted for testing and evaluation purposes. See Contributing for more details on how to setup a local version of Honcho.
Architecture
The functionality of Honcho can be split into two different services: Storage and Insights.
Storage
Honcho contains several different primitives used for storing application and user data. This data is used for managing conversations, modeling user psychology, building RAG applications, and more.
The philosophy behind Honcho is to provide a platform that is user-centric and easily scalable from a single user to a million.
Below is a mapping of the different primitives.
Apps
└── Users
├── Sessions
│ └── Messages
├── Collections
│ └── Documents
└── Metamessages
Users familiar with APIs such as the OpenAI Assistants API will be familiar with much of the mapping here.
Apps
This is the top level construct of Honcho. Developers can register different
Apps for different assistants, agents, AI enabled features, etc. It is a way to
isolation data between use cases.
Users
Within an App everything revolves around a User. the User object
literally represent a user of an application.
Sessions
The Session object represents a set of interactions a User has with an
App. Other application may refer to this as a thread or conversation.
Messages
The Message represents an atomic interaction of a User in a Session.
Messages are labed as either a User or AI message.
Collections
At a high level a Collection is a named group of Documents. Developers
familiar with RAG based applications will be familar with these. Collections
store vector embedded data that developers and agents can retrieve against using
functions like cosine similarity.
Developers can create multiple Collections for a user for different purposes
such as modeling different personas, adding third-party data such as emails and
PDF files, and more.
Documents
As stated before a Document is vector embedded data stored in a Collection.
Metamessages
A Metamessage is similar to a Message with different use case. They are
meant to be used to store intermediate inference from AI assistants or other
derived information that is separate from the main User App interaction
loop. For complicated prompting architectures like metacognitive prompting
metamessages can store thought and reflection steps along with having developer
information such as logs.
Each Metamessage is associated with a User with the ability to optionally
tie to a Session and a Message.
Insights
The Insight functionality of Honcho is built on top of the Storage service. As
Messages and Sessions are created for a User, Honcho will asynchronously
reason about the User's psychology to derive facts about them and store them
in a reserved Collection.
To read more about how this works read our Research Paper
Developers can then leverage these insights in their application to better
server User needs. The primary interface for using these insights is through
the Dialectic Endpoint.
This is a regular API endpoint that takes natural language requests to get data
about the User. This robust design let's us use this single endpoint for all
cases where extra personalization or information about the User is necessary.
A developer's application can treat Honcho as an oracle to the User and
consult it when necessary. Some examples of how to leverage the Dialectic
API include:
- Asking Honcho for a theory-of-mind insight about the
User - Asking Honcho to hydrate a prompt with data about the
Users behavior - Asking Honcho for a 2nd opinion or approach about how to respond to the User
License
Honcho is licensed under the AGPL-3.0 License. Learn more at the License file