Le premier article de cette série opposait RAG et LLM Wiki comme un choix binaire : interpréteur d’un côté, compilateur de l’autre. Ce n’est pas tout à fait exact. Deux techniques génériques, sans auteur-praticien identifiable, le montrent bien, et permettent en même temps de refermer la série sur le terrain plus large où les 9 systèmes ont poussé.
GraphRAG, popularisé par Microsoft Research, précompile déjà une partie du travail que Karpathy attribue à l’ingestion. Plutôt que de se contenter d’indexer des fragments de texte, il construit un graphe d’entités et de relations à partir du corpus, puis génère des résumés de « communautés » de ce graphe, une fois, à l’avance, pas à chaque question. C’est structurellement un pas vers le compilateur : une partie du raisonnement se déplace du moment de la question vers le moment de l’ingestion, exactement comme le prévoit le pattern de Karpathy.
LazyGraphRAG, également propulsé par Microsoft, répond au coût de GraphRAG. Construire un graphe entier et le résumer est onéreux, et souvent inutile pour un corpus qu’on interroge rarement dans son ensemble. LazyGraphRAG retarde une partie de ce travail vers le moment de la requête : il ne précompile que ce qui est nécessaire, quand c’est nécessaire. RAG et compilation ne sont donc pas un interrupteur, mais un curseur réglable.
Les 9 systèmes étudiés occupent des positions différentes sur ce curseur, sans que ce soit toujours nommé ainsi :
- Agrici Daniel et Eugeniu Ghelbur, avec leur compilation active et leur réécriture de pages, sont proches de l’extrémité compilateur.
- Jay Enrique (RoboNuggets), malgré son vocabulaire « Second Brain », est plus proche de l’autre bout : son routage ne recompile rien.
- Garry Tan, lui, combine les deux explicitement, une recherche hybride proche du RAG classique pour la récupération rapide et une couche compilée pour la synthèse. C’est la meilleure illustration, dans ce corpus, que RAG et compilation coexistent plutôt qu’ils ne s’opposent.
Il existe une troisième pièce à ce paysage, plus récente, qui ne porte pas sur la technique de récupération mais sur le format de la connaissance elle-même. En juin 2026, Google Cloud publie une spécification portant précisément ce nom : Open Knowledge Format (OKF). Google la présente sans détour comme la formalisation portable du pattern LLM-wiki de Karpathy, la même source qui ouvre cette série.
OKF n’est ni un nouveau format de stockage, ni un moteur RAG, ni un protocole d’exécution comme MCP. C’est un contrat sémantique : un champ type obligatoire sur chaque fichier, des métadonnées de provenance, de fraîcheur et de vérification (sources, verified, stale_after) qui permettent à plusieurs outils, agents ou utilisateurs de lire et d’écrire le même corpus sans en apprendre le dialecte propriétaire à chaque fois.
Sa valeur croît avec le nombre d’agents et d’outils qui partagent un même substrat, exactement le terrain que cette série appelle une Infrastructure Agentique Personnelle (IAP, article 1). Rien, dans le corpus étudié ici, n’indique qu’un seul des 9 systèmes l’implémente à ce jour. Je le mentionne donc comme une tendance émergente de 2026, pas comme une fonctionnalité vérifiée dans l’un des 9 systèmes.
Reste la couche logicielle sur laquelle les 9 systèmes se construisent, les harnais agentiques. OpenClaw et Hermes Agent en sont les deux noms qui reviennent le plus souvent dans les corpus sources (Claude Code, Codex et OpenCode en sont d’autres exemples). Fait notable, déjà croisé au premier article : les deux existaient avant le Gist de Karpathy, mémoire de fonctionnement comprise, et l’ont absorbé après coup.
Hermes embarque désormais un skill nommé « Karpathy’s LLM Wiki ». OpenClaw propose un plugin memory-wiki. Garry Tan est, dans ce corpus, le système qui documente le pont le plus direct vers ces deux harnais.
OKF et les harnais agentiques ne se recouvrent pas. Les harnais sont la couche d’exécution, celle qui décide et agit. OKF est la couche de connaissance, celle qui se lit et s’écrit. Les deux se complètent plutôt qu’ils ne rivalisent.
Pourquoi ne pas en faire des systèmes de plus dans cette étude ? Pas une question de complexité, mais de nature. GraphRAG, LazyGraphRAG, OKF, OpenClaw et Hermes n’ont pas d’auteur-praticien identifiable, pas de pratique personnelle comparable aux 9 de cette série. C’est le terrain sur lequel les 9 systèmes sont construits, pas des pratiques supplémentaires à leur ajouter.
Reste à refermer ce que ces 9 systèmes, eux, ont montré :
- La bibliothèque vivante répond à « que sais-je ? » : Karpathy, Agrici Daniel, Eugeniu Ghelbur et Mark Kashef lisent, rangent, relient et corrigent un fonds de connaissances.
- Le partenaire contextualisé répond à « aide-moi à penser et produire ceci ». Tiago Forte et Nick Milo mobilisent un contexte personnel pour nourrir un dialogue.
- L’atelier opérationnel répond à « que faut-il faire ensuite ? ». Garry Tan, RoboNuggets et Eliott Meunier y accomplissent du travail, parfois sans qu’on le leur redemande.
Trois métiers, sans hiérarchie entre eux, comme le rappelait l’article 2.
Pour qui veut aller plus loin que ces 9 articles, un document technique complet est en préparation à partir du même corpus. Cette série s’arrête ici, mais le guide, lui, continue de s’écrire !
Série de 9 articles pour Comprendre les Infrastructures Agentiques Personnelles :
- Le texte qui a tout déclenché
- Trois familles, pas un classement
- Trois questions avant de croire un vocabulaire
- La bibliothèque qui s’écrit elle-même
- Le partenaire qui vous connaît déjà
- L’atelier qui produit en circuit court
- Le meilleur système n’existe pas
- La mémoire qui se trompe en se corrigeant
- Le terrain sous les 9 systèmes