Une wiki LLM façon Karpathy maintenue par des agents (Markdown et Git)

WUPHF — nom tiré d'une blague de la série The Office — est un framework open-source publié sous licence MIT qui organise un ensemble d'agents IA en "bureau collaboratif", chacun doté d'un rôle défini (CEO, PM, ingénieurs, designer, CMO, CRO) et d'une mémoire partagée sous forme de wiki versionné. Le projet, écrit principalement en Go (72,9 % du code) et TypeScript, est accessible via une simple commande `npx wuphf` qui ouvre automatiquement une interface web locale.

L'architecture repose sur une distinction nette entre mémoire privée et mémoire partagée. Chaque agent dispose d'un notebook personnel, espace de travail local et non diffusé, dans lequel il consigne observations et contexte en cours de tâche. Lorsqu'une information est jugée suffisamment stable — un playbook récurrent, un fait vérifié, une préférence confirmée — l'agent peut la "promouvoir" vers le wiki d'équipe. Cette promotion est explicite et à l'initiative de l'agent : rien n'est transféré automatiquement. Le wiki partagé constitue la mémoire collective, interrogeable par l'ensemble des agents via des outils MCP dédiés (team_wiki_read, team_wiki_search, wuphf_wiki_lookup, etc.).

Le backend par défaut depuis la version 0.0.6 est `markdown`, un dépôt Git local stocké dans `~/.wuphf/wiki/`. La description du projet insiste sur le fait qu'il ne s'agit pas d'un simple dossier de fichiers plats : le système gère des triplets de faits typés, des journaux d'ajouts par entité, des synthèses générées par LLM commitées sous une identité "archivist", et une commande `/lint` capable de détecter contradictions, liens orphelins et références obsolètes. L'ensemble reste accessible par les outils Unix standards (`cat`, `grep`, `git log`), sans clé API nécessaire pour ce backend. Deux alternatives existent : `nex`, l'ancien backend par défaut qui requiert une clé API Nex/WUPHF, et `gbrain`, qui monte un service externe avec embeddings et recherche vectorielle via OpenAI.

L'aspect "Karpathy-style" mentionné dans la documentation renvoie à l'idée d'un wiki LLM pédagogique et lisible, où chaque contribution est traçable via l'historique Git. Un script de démonstration illustre la boucle complète : un agent enregistre cinq faits, un seuil de synthèse se déclenche, le broker appelle le CLI LLM local, le résultat est commité sous l'identité archivist, et la chaîne d'auteurs est visible dans `git log`. Ce mécanisme offre une auditabilité native sans infrastructure supplémentaire.

Sur le plan des performances, le projet publie un benchmark comparant WUPHF à des orchestrateurs à session accumulée. Sur une session de dix tours avec un CEO sur Codex, WUPHF maintient un volume d'entrée plat d'environ 87 000 tokens par tour, avec une facturation effective d'environ 40 000 tokens après cache. Le taux de cache hit atteint 97 % sur l'API Claude grâce à des préfixes de prompts identiques entre sessions fraîches. À titre de comparaison, les orchestrateurs à contexte cumulé passent selon le projet de 124 000 à 484 000 tokens d'entrée sur la même durée, soit un facteur 7 mesuré sur huit tours. La consommation idle est nulle : les agents sont déclenchés par push du broker, sans polling.

La compatibilité s'étend à Claude Code, Codex CLI, OpenClaw et les LLMs locaux via OpenCode. Des bridges sont disponibles pour Telegram et pour les agents OpenClaw existants, ces derniers rejoignant le bureau comme membres à part entière adressables par @mention. Deux fournisseurs d'actions externes sont supportés : un CLI local (défaut) et Composio pour les intégrations SaaS hébergées. Un système de compétences publiables (`wuphf skills publish`) permet de partager des skills d'équipe vers des hubs publics (Anthropic, LobeHub, ou tout dépôt GitHub custom) et d'en installer depuis ces mêmes sources.

Le projet se présente explicitement comme pre-1.0, avec une branche `main` en mouvement quotidien. La recommandation officielle est de pinner les forks sur un tag de release. Avec 937 étoiles et 68 forks au moment de la publication, et 328 releases déjà produites, l'activité de développement est soutenue. Les questions ouvertes concernent notamment la robustesse du mécanisme de promotion (qui repose sur le jugement des agents eux-mêmes), la gestion des conflits dans le wiki Git en environnement multi-agents concurrent, et la scalabilité du modèle "session fraîche par tour" pour des tâches longues nécessitant un contexte étendu.