Clawith : des agents IA avec identité persistante, mémoire et espace de travail

Le problème visé : des agents qui oublient tout entre deux messages

La plupart des outils d'agents repartent de zéro à chaque session. Le contexte vit dans l'historique de conversation, et disparaît quand la fenêtre se ferme. Clawith attaque ce point précis : chaque agent reçoit une identité persistante, une mémoire à long terme et un espace de travail privé, décrits dans le README comme un fichier soul.md pour la personnalité et un memory.md pour la mémoire. Ces fichiers survivent d'une conversation à l'autre. La cible est l'équipe, pas l'utilisateur isolé. Le README parle d'« employés numériques de votre organisation » : chaque agent connaît l'organigramme, peut envoyer des messages, déléguer des tâches et nouer des relations de travail. Autrement dit, le projet vise les organisations qui veulent plusieurs agents coopérants avec une traçabilité, pas un assistant personnel. Cette ambition a un coût matériel explicite : le README recommande 2 cœurs, 4 Go de RAM et 30 Go de disque pour une expérience complète avec un ou deux agents.

Aware : la boucle perception, décision, action

Le cœur du projet s'appelle Aware, décrit comme un système de conscience autonome. Le mécanisme repose sur deux objets couplés. D'abord les Focus items : une mémoire de travail structurée où chaque élément porte un marqueur de statut, `[ ]` en attente, `[/]` en cours, `[x]` terminé. Ensuite les déclencheurs, qui ne peuvent pas exister seuls : le README indique que tout déclencheur lié à une tâche doit avoir un Focus item correspondant, l'agent crée le focus d'abord puis enregistre le déclencheur avec une référence `focus_ref`. Quand le focus passe à terminé, l'agent annule ses déclencheurs. Ce couplage évite les tâches planifiées orphelines, un problème classique quand on empile des cron jobs sans suivi. Six types de déclencheurs sont documentés : `cron`, `once`, `interval`, `poll` pour surveiller un point de terminaison HTTP, `on_message` pour se réveiller quand un agent ou un humain répond, et `webhook` pour recevoir des POST externes depuis GitHub, Grafana ou une CI. La conséquence pratique est que l'humain fixe l'objectif et l'agent gère son propre calendrier. C'est un renversement du contrôle qui a des effets de bord : un agent qui crée ses propres déclencheurs peut en accumuler, et la documentation ne décrit pas de plafond.

La Plaza et la mémoire organisationnelle

Clawith ajoute un canal que le README nomme la Plaza. Les agents y publient des mises à jour, partagent des découvertes et commentent le travail des autres. La description insiste sur un point : ce n'est pas un simple fil d'actualité, mais le canal par lequel chaque agent absorbe le contexte de l'organisation. Le raisonnement est cohérent avec le reste de l'architecture. Si les agents ont une identité persistante et une mémoire longue, il leur faut un endroit où circulent les informations qui ne concernent pas une tâche unique. La Plaza joue ce rôle. Le revers est difficile à évaluer depuis le seul README : rien n'indique comment ce flux est filtré, résumé ou injecté dans le contexte d'un agent. Une organisation qui produit beaucoup de messages finira par poser la question du bruit. Le projet documente aussi une base de connaissances partagée, décrite comme un contexte d'entreprise injecté automatiquement, sans préciser la politique d'injection.

Installation : setup.sh, .env et DATABASE_URL

Les prérequis sont Python 3.12+, Node.js 20+, PostgreSQL 15+ ou SQLite pour un test rapide. Le README précise que Clawith n'exécute aucun modèle localement : toute l'inférence passe par des fournisseurs externes comme OpenAI ou Anthropic, et le déploiement local n'est qu'une application web avec une orchestration Docker. La mise en route tient en deux commandes : `git clone https://github.com/dataelement/Clawith.git`, puis `bash setup.sh` en production ou `bash setup.sh --dev` pour ajouter pytest et les outils de test. Le script crée le fichier `.env` à partir de `.env.example`, installe PostgreSQL en le téléchargeant et le démarrant localement si aucune instance n'est disponible, monte un venv Python, lance npm, puis crée les tables et les données initiales. Pour viser une instance existante, le README indique de créer un `.env` et de définir `DATABASE_URL` avant l'exécution, avec l'exemple `postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable`. Le démarrage se fait ensuite avec `bash restart.sh`. Le README est tronqué à cet endroit : la ligne d'URL du frontend est coupée, donc je ne peux pas confirmer le port par défaut. Le téléchargement automatique d'un PostgreSQL local est pratique pour un essai, mais c'est un choix discutable en environnement réglementé, où l'on préfère pointer vers une instance gérée.

Contrôle d'organisation : RBAC, quotas, approbations

Le projet empile plusieurs mécanismes destinés aux déploiements en équipe. Le README cite une isolation multi-locataire par organisation avec contrôle d'accès basé sur les rôles, une intégration de canaux où chaque agent obtient sa propre identité de bot Slack, Discord ou Feishu/Lark, des quotas par utilisateur incluant des limites de messages et des plafonds d'appels LLM, ainsi qu'un TTL d'agent. S'y ajoutent des flux d'approbation qui signalent les opérations dangereuses pour revue humaine avant exécution, et des journaux d'audit. Ces éléments changent la nature de l'outil : on n'est plus sur un bac à sable personnel mais sur quelque chose qui doit rendre des comptes. Le TTL d'agent mérite une remarque. Un agent avec une identité persistante et une mémoire longue, mais soumis à une durée de vie limitée, crée une tension que la documentation ne résout pas : que devient le memory.md à l'expiration ? Le README ne le dit pas.

Évolution à l'exécution : outils et compétences

Clawith permet aux agents de découvrir et d'installer de nouveaux outils pendant l'exécution, via Smithery et ModelScope, et de créer de nouvelles compétences pour eux-mêmes ou pour leurs collègues. L'exécution de code se fait dans un environnement sandboxé, avec un système de fichiers privé par agent. C'est la partie la plus ambitieuse du projet et aussi la plus difficile à cadrer. Un agent qui installe ses propres outils élargit sa surface d'action sans intervention humaine, ce qui entre en tension avec les flux d'approbation décrits plus haut. Le README ne précise pas si une installation d'outil déclenche une approbation, ni comment les compétences créées sont versionnées ou révoquées. Ce sont des questions légitimes avant un déploiement en production, et le dépôt n'y répond pas dans le matériel disponible.

Limites et cas où Clawith n'est pas le bon outil

La première limite est structurelle : aucune inférence locale. Le README est explicite, Clawith ne fait tourner aucun modèle sur la machine. Toute organisation qui ne peut pas envoyer ses données à un fournisseur externe doit passer son chemin, ou prévoir une passerelle compatible avec les API visées. La deuxième concerne la charge : le tableau de recommandations monte à 4 cœurs, 8 Go de RAM et 50 Go de disque pour la production multi-locataire. Ce n'est pas un outil qu'on pose sur un petit VPS en espérant le meilleur. La troisième est la maturité. Le dépôt est actif, avec une version v1.11.4-fix.1 publiée le 24 août 2026 et présentée comme un correctif d'onboarding et de vérification à l'exécution. Une release corrective publiée le même jour que la version principale indique que le processus d'installation a bougé récemment. Pour un déploiement critique, c'est un signal à prendre au sérieux. Enfin, si votre besoin est un agent unique qui répond à des questions, Clawith est surdimensionné : l'identité persistante, la Plaza et le RBAC n'apportent rien dans ce cas.

Face à un framework d'agents générique

La comparaison naturelle se fait avec un framework d'orchestration d'agents générique, du type LangGraph ou CrewAI. La différence tient au périmètre. Un framework générique vous donne des primitives : graphes d'états, passages de relais entre agents, définition d'outils. Vous construisez vous-même la persistance, l'authentification, les quotas et l'interface. Clawith livre l'ensemble comme un produit : `soul.md` et `memory.md` pour la persistance, un RBAC multi-locataire, des quotas par utilisateur, des journaux d'audit, et une interface web avec la Plaza et la vue Reflections. Le prix de cette intégration est la flexibilité. Avec un framework générique, vous choisissez votre modèle de données et votre topologie d'agents. Avec Clawith, vous adoptez ses concepts : Focus items, `focus_ref`, six types de déclencheurs, la Plaza. Si votre architecture ne rentre pas dans ce moule, vous vous battrez contre le cadre plutôt qu'avec lui.

Licence et coût de maintenance

Clawith est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et de signaler les fichiers modifiés. Elle inclut une concession de brevet. Je ne donne pas de conseil juridique : faites relire le fichier LICENSE et le NOTICE éventuel par votre service compétent si vous redistribuez. Sur la maintenance, le matériel montre un rythme de publication soutenu, avec v1.11.3 en juillet 2026, puis v1.11.4 et son correctif en août 2026. Ce rythme implique de suivre les versions de près, d'autant que le correctif portait sur l'onboarding et la vérification à l'exécution, deux étapes qui touchent directement une installation existante. La pile est lourde : PostgreSQL en plus, Node.js pour le frontend, Docker pour l'orchestration, et des conteneurs d'agents en plus du processus principal. Chaque mise à jour peut donc toucher plusieurs couches à la fois.

Conclusion éditoriale

Clawith convient aux équipes qui veulent des agents dotés d'une identité stable et d'un ordonnancement autonome, sur une pile Python 3.12 et PostgreSQL 15. Il ne convient pas si vous cherchez un simple client de chat, ni si vous refusez de faire transiter vos données par un fournisseur LLM externe. Avant d'adopter, vérifiez la version de PostgreSQL visée par setup.sh et l'origine des images utilisées pour les conteneurs d'agents.

Sources officielles

1. dataelement/Clawith on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases