Honcho : mémoire à base de raisonnement pour agents avec état
Memory library for building stateful agents
En bref
- De quoi s’agit-il ?
- Honcho est une bibliothèque Python qui stocke messages et événements, les fait raisonner en arrière-plan et expose des représentations par pair. Voici ce que le dépôt permet de vérifier, et les points à contrôler avant de l'adopter.
- À qui s’adresse-t-il ?
- Honcho convient aux équipes qui ont besoin de représentations par pair avec une phase de raisonnement asynchrone et qui acceptent d'exploiter un service FastAPI en plus de leur application, soit via api.honcho.dev, soit via honcho start --setup. Il ne convient pas si vous cherchez uniquement un magasin de vecteurs à brancher sur une base existante, ni si l'AGPL-3.0 est incompatible avec la distribution de votre produit.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions strictes. AGPL-3.0 est une licence à copyleft réseau : si des personnes utilisent une version modifiée via un réseau, par exemple comme service hébergé, vous devez leur proposer son code source sous la même licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : des agents qui gardent une image des personnes
La plupart des agents repartent de zéro à chaque appel. On contourne cela en recollant les derniers messages dans le prompt, ce qui fonctionne jusqu'au moment où la conversation dépasse la fenêtre de contexte ou s'étale sur plusieurs semaines. Honcho prend le problème par l'autre bout : il conserve les messages et les événements, puis construit une représentation par pair que l'on interroge séparément. Le README présente l'outil comme une infrastructure de mémoire pour des agents qui doivent comprendre des personnes, des agents, des groupes, des projets et des idées qui changent. Le public visé est donc l'équipe qui intègre un agent conversationnel dans un produit et qui veut interroger une mémoire plutôt que relire un journal brut. Deux modes d'exploitation sont proposés : le service hébergé sur api.honcho.dev, ou une pile locale démarrée par la CLI.
Workspaces, peers, sessions : la hiérarchie réelle
Le dépôt décrit une organisation en quatre niveaux. Un workspace contient des peers. Les peers participent à des sessions. Les messages vivent sur les sessions. Honcho construit ensuite une représentation par peer, que l'on interroge via le Chat Endpoint ou directement. Cette hiérarchie a une conséquence pratique : un même utilisateur peut apparaître dans plusieurs sessions sans que vous ayez à recopier son historique, puisque la représentation est attachée au peer et non à la session. Le README mentionne aussi une perspective multi-peer, décrite comme la capacité de modéliser ce qu'un peer sait d'un autre lorsque la configuration le prévoit. C'est une nuance importante : cette fonctionnalité n'est pas présentée comme active par défaut, et le document ne détaille pas les clés de configuration correspondantes. Si votre cas d'usage repose sur cette modélisation croisée, prévoyez de lire la documentation en ligne avant de dimensionner quoi que ce soit.
La boucle store, reason, query, inject
Le mécanisme se lit en quatre temps. On stocke d'abord des conversations, des événements, des documents ou des traces d'outils sous forme de messages sur une session. Honcho traite ensuite une file en arrière-plan et met à jour les représentations des peers. On interroge enfin l'ensemble : contexte, résultats de recherche, représentation d'un peer, ou réponse en langage naturel. On injecte le résultat dans n'importe quel appel LLM. Le point à retenir est le caractère asynchrone du raisonnement. Le README indique explicitement que cette étape se produit en arrière-plan, ce qui signifie qu'un message ajouté n'est pas immédiatement reflété dans la représentation. Le code d'exemple enchaîne d'ailleurs add_messages puis un appel à alice.chat sans mécanisme d'attente visible. Pour un agent qui doit répondre dans la même seconde, cette latence est un choix de conception à intégrer, pas un détail d'implémentation.
Mise en route : SDK, CLI et variables d'environnement
Côté Python, l'installation se fait par pip install honcho-ai, ou uv add honcho-ai, ou poetry add honcho. L'import se fait depuis le module honcho, avec une classe Honcho prenant workspace_id et api_key. Le README précise que le service hébergé utilise api.honcho.dev par défaut et que, pour une instance locale, il faut passer base_url="http://localhost:8000" ou définir HONCHO_URL. Côté TypeScript, le paquet est @honcho-ai/sdk, installable par npm install @honcho-ai/sdk ou bun add @honcho-ai/sdk, avec un constructeur qui prend workspaceId et apiKey. Pour l'exécution locale, le chemin indiqué est honcho start --setup, avec un SDK pointé vers http://localhost:8000. L'inspection d'un déploiement se fait par honcho workspace inspect et honcho doctor. Le README mentionne aussi un auto-hébergement par Docker Compose ou en développement local, et un serveur FastAPI que l'on peut exécuter soi-même. Ces deux derniers points ne sont pas détaillés dans l'extrait disponible.
Deux limites qui décident de l'adéquation
Première limite : le raisonnement en arrière-plan introduit une fenêtre pendant laquelle la mémoire est en retard sur la conversation. Le README ne documente ni la profondeur de la file, ni les garanties d'ordre, ni les mécanismes de reprise après incident. Une équipe qui construit un agent où chaque tour doit refléter le précédent devra tester ce comportement avant de s'engager. Deuxième limite : Honcho s'ajoute à votre pile. Que vous preniez le service hébergé ou que vous exécutiez le serveur FastAPI vous-même, vous introduisez un composant réseau entre votre application et sa mémoire. Le mode local par honcho start --setup réduit la dépendance externe mais déplace la charge d'exploitation vers votre équipe. Le README ne fournit aucune indication de dimensionnement, ni sur le stockage requis, ni sur les modèles utilisés pour le raisonnement, ni sur les coûts associés. Ces éléments manquent pour arbitrer entre les deux modes.
Ce qui distingue Honcho d'une base vectorielle
L'alternative la plus directe est la pile classique : une base vectorielle, un découpage de documents, une recherche par similarité, et le collage des fragments les plus proches dans le prompt. La différence tient à la phase de raisonnement. Une base vectorielle retrouve des passages qui ressemblent à la requête. Honcho, selon sa propre description, extrait des conclusions à partir des conversations et des événements plutôt que de se limiter à apparier des morceaux. Cela change la nature de ce que l'on stocke : d'un côté des fragments indexés, de l'autre des représentations mises à jour. Cela change aussi le coût : la recherche vectorielle est déterministe et synchrone, le raisonnement est asynchrone et consomme des appels de modèle. Une équipe qui a seulement besoin de retrouver un passage précis dans une documentation n'a rien à gagner à faire tourner un serveur FastAPI supplémentaire.
Licence AGPL-3.0 et coût de maintenance
Le dépôt est publié sous AGPL-3.0. Cette licence impose des obligations lorsque le logiciel est mis à disposition par un service en ligne : le code source correspondant doit être proposé aux utilisateurs de ce service. C'est une contrainte à examiner avec votre juriste avant d'intégrer Honcho dans un produit distribué ou hébergé, car elle diffère nettement de celle d'une licence permissive. Le README reste discret sur la maintenance. Aucune version publiée n'apparaît dans les informations récupérées, ce qui empêche de juger le rythme des versions. Le projet se répartit sur plusieurs dépôts, avec les SDK dans sdks/ et le paquet honcho-cli dans le même dépôt que le serveur. Ce découpage implique de suivre les versions du serveur, du SDK Python et du SDK TypeScript séparément. Le README affiche un badge indiquant une version de serveur, mais sans historique de publication, il est impossible de dire si cette version est stable ou récente.
Conclusion éditoriale
Honcho convient aux équipes qui ont besoin de représentations par pair avec une phase de raisonnement asynchrone et qui acceptent d'exploiter un service FastAPI en plus de leur application, soit via api.honcho.dev, soit via honcho start --setup. Il ne convient pas si vous cherchez uniquement un magasin de vecteurs à brancher sur une base existante, ni si l'AGPL-3.0 est incompatible avec la distribution de votre produit. Avant de vous engager, vérifiez trois choses concrètes : le comportement de la file de raisonnement en cas de rafale de messages, la sortie de honcho doctor sur votre déploiement, et le format exact de session.context(summary=True, tokens=10_000) pour votre modèle cible.
Notes de la communauté