KAIROS : un daemon, pas un assistant
Le mot qui change tout : daemon. Un processus en arrière-plan, indépendant de toute interaction utilisateur. Ton serveur web, ton gestionnaire de DB, ton scheduler — ce sont des daemons.
KAIROS est ça. Sauf que c’est un LLM.
Selon le code source fuité, KAIROS fonctionne en mode background persistant. Actif même laptop fermé. Survit aux redémarrages. Reçoit des « periodic tick prompts » — déclencheurs réguliers qui l’amènent à agir de sa propre initiative.
Tu fermes ton ordinateur, tu vas déjeuner, tu reviens. KAIROS a peut-être fait des choses pendant ce temps.
15 secondes — chaque décision proactive est limitée à 15 secondes. Actions courtes, ciblées. Analyser un diff, pousser une notification, livrer un fichier. Pas refactoriser une codebase entière.
3 outils exclusifs à KAIROS, absents du mode interactif standard :
- PushNotification — l’agent peut te contacter, pas seulement répondre
- FileDelivery — livraison de fichiers en arrière-plan
- SubscribePR — abonnement aux pull requests, surveillance continue du dépôt
Feature flags identifiés dans le code : KAIROS et KAIROS_GITHUB_WEBHOOKS. Présents. Pas encore activés en production publique.
Dernier détail qui compte : les logs sont append-only, au format JSONL, journaliers. L’agent ne peut pas effacer ses propres traces. Chaque action est tracée, la trace est immuable du point de vue de l’agent. C’est une décision d’architecture qui parle d’elle-même.
autoDream : quand l’agent consolide sa mémoire
Le problème de fond : un LLM en mode API est apatride. Pas de mémoire entre sessions. Tu réexpliques tout à chaque fois. L’approche naïve — balancer tout le contexte à chaque appel — coûte des tokens et dilue l’attention du modèle.
autoDream est la réponse d’Anthropic à ce problème. Il se déclenche pendant les périodes d’inactivité, via un sous-agent forké avec accès limité (ce cloisonnement empêche la corruption du contexte principal). Ce sous-agent cible les transcripts JSONL de toutes les sessions passées.
Il fait trois choses :
- Fusionner des observations disparates pointant vers le même fait
- Supprimer les contradictions logiques accumulées
- Convertir des insights vagues en faits absolus, avec date et source
La sortie : un fichier MEMORY.md. Index structuré, environ 150 caractères par ligne, 200 lignes chargées au démarrage de chaque session. Le minimum requis pour que l’agent « se souvienne » de qui tu es et de l’état de ton projet.
« NeuroDream » (SSRN 5377250) — la phase de rêve appliquée aux agents IA : 38 % de réduction du forgetting, 17,6 % d’amélioration zero-shot transfer. Bases biologiques : synaptic homeostasis hypothesis, replay hippocampique en slow-wave sleep.
Ce n’est pas de la métaphore. L’inspiration neuroscientifique est revendiquée, les résultats mesurés. Le survey « Memory in the Age of AI Agents » (arXiv 2512.13564, janvier 2026) positionne ce type d’architecture comme l’une des plus prometteuses pour les agents persistants.
L’architecture mémoire en 3 couches
La mémoire de KAIROS n’est pas un fichier plat. C’est une pile à trois niveaux, chaque couche ayant un rôle distinct.
- Couche 1 — L’index (MEMORY.md) : toujours chargé, pointeurs uniquement. La table des matières de la mémoire.
- Couche 2 — Les topic files : contenu factuel, chargé à la demande selon la pertinence de la session.
- Couche 3 — Les session transcripts : JSONL append-only. La matière première brute pour autoDream.
En parallèle, cinq stratégies de compaction de contexte sont implémentées pour éviter de dépasser les limites du modèle :
- Microcompact (Tier 1) : clearing des tool results avant chaque API call
- Server-side (Tier 2) : clearing au niveau API des thinking blocks
- Full LLM summarization (Tier 3) : résumé structuré en 9 sections quand le contexte approche de la limite
- Cache_edits blocks : suppression chirurgicale de blocs par ID
- Subagent isolation : chaque sous-agent reçoit un contexte vierge
Le tournant stratégique : stateless vers stateful
Pour comprendre ce que KAIROS représente, il faut replacer dans la chronologie des agents IA.
2023 : AutoGPT, BabyAGI. Des preuves de concept. Le hype était au maximum, l’utilité en production quasi nulle. Mémoire inexistante entre sessions.
2024–2025 : Cursor Agent Mode (8 agents parallèles, plus d’un million d’utilisateurs), Devin (premier « AI software developer »), Windsurf Cascade. Utiles sur tâches bornées, mais toujours stateless entre sessions. Tu recommences à zéro à chaque fois.
2026 : KAIROS. Première tentative commerciale sérieuse d’un daemon IA always-on avec consolidation mémorielle organisée.
Ce n’est pas la puissance du modèle. C’est la persistance. Une API LLM est stateless — la session se termine, tout s’efface. Un CLI daemon est stateful — la session ne se termine pas. La mémoire persiste et se consolide.
Le pari d’Anthropic : pas un meilleur assistant de code. Un collègue numérique qui accumule du contexte sur ton projet, tes habitudes, tes décisions d’architecture, et qui devient plus utile semaine après semaine.
L’impact compétitif : le blueprint gratuit
Anthropic n’a pas encore lancé KAIROS publiquement. Les feature flags sont là, l’architecture est en place. Mais pas dans la version publique de Claude Code.
Les zones d’ombre
ANTI_DISTILLATION_CC
Ce feature flag mérite un paragraphe à part. Quand il est actif — sous 4 conditions spécifiques identifiées dans le code — le système injecte de faux outils dans les réponses pour polluer les données d’entraînement des concurrents.
Défense active contre la distillation. Légalement discutable. Révélateur d’une guerre industrielle souterraine entre labs qui ne se réduit pas aux benchmarks publics.
Détection de frustration
Un fichier userPromptKeywords.ts contient des regex ciblant les expressions de frustration utilisateur : « wtf », « shit », « awful », « so frustrating ». Pas d’inférence LLM — une regex de 200 caractères coûte zéro token. Décision pragmatique. L’agent détecte quand tu es en train de craquer.
Undercover Mode
Un prompt système intitulé « You are operating UNDERCOVER » empêche les employés Anthropic de révéler l’usage de Claude Code dans des projets open-source. Non désactivable par l’utilisateur. Ce point est mentionné sans commentaire supplémentaire.
Ce qui arrive ensuite
D’autres feature flags identifiés dans le code source pointent vers la suite de la roadmap :
- COORDINATOR_MODE : orchestration multi-agents, un coordinateur + pool de workers via système mailbox
- ULTRAPLAN : session de planning cloud de 30 minutes maximum, approbation via navigateur
- VOICE_MODE : push-to-talk
- BUDDY : Tamagotchi terminal, 18 espèces, variante Shiny « Nebulynx » liée à un token Solana. Vraisemblablement un poisson d’avril 2026.
La question qui reste ouverte
Un daemon IA avec accès filesystem, qui agit laptop fermé, qui consolide des observations en faits pendant les périodes d’inactivité — la surface d’attaque est non triviale.
Les décisions d’architecture vont dans le bon sens : logs append-only (bonne décision), cloisonnement du sous-agent autoDream (bonne décision), budget 15 secondes qui limite l’impact de chaque action (bonne décision).
Mais la question qui n’a pas de réponse dans le code source fuité : qu’est-ce qu’autoDream considère comme un « insight vague à convertir en fait absolu » ? Qui audite ce processus de consolidation ? Comment un utilisateur sait ce que l’agent a retenu de lui après six mois d’usage ?
La transparence sur la mémoire d’un agent persistant est un problème non résolu. KAIROS en est probablement la première implémentation commerciale à cette échelle.
Ce que ça donne en production, on ne le saura qu’avec des mois d’utilisation réelle. Selon le code fuité, le feature flag KAIROS est là. Le reste, c’est une question de timing.