Mon AI Chief of Staff avec Claude Code : 12 jours après

Et si votre IA se souvenait d'un Slack vieux d'un mois pour répondre à un mail de ce matin ? Douze jours après son lancement, mon Chief of Staff IA "Life" a franchi un cap : celui de la continuité de contexte. Derrière les 304 messages échangés se cache une architecture invisible mais robuste que j'ai dû reconstruire de zéro. Retour sur ce qui a changé quand mon agent a commencé à connecter les points entre mes différents outils.

Ca fait plusieurs semaines que j'utilise Life tous les jours et que je l'améliore. Il était temps de rédiger la suite de mon premier article.

Rappel rapide pour ceux qui arrivent ici directement : j'ai monté un agent personnel qui tourne 24/7, accessible depuis Telegram, propulsé par Claude Code avec un fichier CLAUDE.md pour le contexte permanent et des skills modulaires pour les cas d'usage. L'intention est la même : un assistant qui me suit partout, lit mes mails, gère mes tâches, prépare mes messages, et apprend au fur et à mesure.

En revanche, tout le reste a changé.

• Feedback après quelques semaines d'usage réel
• Ce que j'ai fait évoluer techniquement
• Les grandes évolutions fonctionnelles
• What's next
• Ce que je retiens vraiment

Feedback après quelques semaines d'usage réel

Les chiffres d'abord, parce qu'ils racontent quelque chose d'intéressant.

Sur douze jours d'usage réel au quotidien : 304 messages échangés avec Life. 171 côté Telegram, 121 côté Slack (qu'il ingère maintenant pour mieux me suivre), et le reste en canaux divers. 13 skills actifs. 27 fichiers mémoire auto-générés qui font que chaque nouvelle conversation démarre avec du contexte plutôt qu'avec une page blanche.

Sur le plan qualitatif, deux observations.

• Il y a réellement des moments bluffants. Je ne parle pas de démos, mais de moments précis où Life a fait une chose que je n'aurais pas faite moi-même. Presque tous ces moments sont des moments de raisonnement cross-source : Life combine plusieurs informations venues de canaux différents et produit quelque chose que je n'aurais pas produit aussi vite.

• L'essai-erreur est énorme, mais plus technique que fonctionnel. La plupart des heures que j'y ai mises n'ont pas été consacrées à inventer de nouveaux skills : elles ont été consacrées à rendre l'infrastructure robuste. Optimiser les tokens, contourner les limites des MCPs, installer une mémoire qui survit aux redémarrages, gérer les crons qui sautent quand mon Mac passe en clamshell... Du build d'infra pur.

Ca peut paraître ingrat, mais c'est ce qui fait que Life passe du stade de "démo cool" à celui d'outil utilisé tous les jours.

Ce que j'ai fait évoluer techniquement, et pourquoi

J'ai mené trois gros chantiers.

Chantier 1 : le mur des tokens

Très vite, je me suis pris les quotas Anthropic en pleine face. Claude Code consomme du contexte à la vitesse de la lumière quand tu lui demandes de lire des mails, parcourir des threads Slack, ou regarder des transcripts Granola. La semaine où j'ai commencé à vraiment utiliser Life au quotidien, j'ai vu mon usage journalier doubler, puis tripler.

J'ai choisi deux réponses en parallèle pour faire face à cette surconsommation.

• La première : RTK, un petit proxy CLI qui intercepte les commandes bash courantes (git status, ls, lecture de fichiers longs) et renvoie une version condensée au modèle. Sur les 53 commandes les plus fréquentes, il m'a économisé 396 000 tokens, soit 84% d'économie sur le trafic concerné. Un petit outil, un gros gain.

• La deuxième : remplacement systématique des MCPs par des CLIs pour tout ce qui tourne en cron. Les MCPs sont brillants quand tu bosses en interactif avec Claude Code. Ils ne marchent pas en session non-interactive. Autant j'apprécie la magie d'un MCP Gmail, autant je ne veux pas que mon brief matinal plante tous les lundis parce que la session n'est pas connectée. J'ai donc wrappé : gws (Google Workspace) - remplace les MCPs Gmail + Calendar. Helpers +triage, +read, +agenda, +insert - et granola : CLI qui remplace le MCP Granola pour les transcripts de réunion.

Résultat : tout ce qui tourne en LaunchAgent (brief matinal, triage email 4x/jour) fonctionne sans jamais charger un MCP. Je reconnais que c'est peut-être moins séduisant sur un slide d'archi, mais c'est beaucoup plus fiable dans la vraie vie !

Chantier 2 : une vraie mémoire

Dans la V1, je mentionnais la mémoire persistante comme un "what's next". C'est fait ! Et c'est probablement le chantier qui a le plus changé la donne.

J'ai mis en place trois couches de mémoire :

• Transcript store (SQLite + FTS5). Chaque message entrant sur Telegram, chaque réponse, chaque ingestion Slack finit dans une base indexée full-text. Quand je pose une question à Life, un script récupère les conversations passées pertinentes et les injecte en contexte. Life ne me dit plus "je ne me souviens pas". Il me dit "d'ailleurs la semaine dernière tu avais dit X".

• Hot context. Un fichier hot-context.md d'environ 500 tokens, compilé automatiquement, qui décrit mes projets actifs, mes décisions récentes et mes follow-ups en cours, et qui est chargé à chaque session. Coût : négligeable. Impact : énorme, parce que Life n'arrive plus "nu" dans une conversation.

• Mémoire typée auto-apprise. Quatre types de fiches : user, feedback, project, reference. Chaque fois que je corrige Life ou que je lui fais un retour, il génère une fiche persistante avec un bloc "Why" et un bloc "How to apply". J'en suis à 27 fiches aujourd'hui.

Je vais donner un exemple concret de la valeur que ça m'apporte. Un jour, je lui demande d'archiver un mail. Deux heures plus tard, je retrouve le même mail dans ma boîte : je l'engueule. Life comprend qu'il archivait uniquement le messageId affiché et pas le thread complet. Il corrige le script, documente le cas dans son SKILL.md, et pose une règle permanente en mémoire. Depuis, tous les archives passent au niveau thread. Je n'ai jamais à redire la même chose deux fois.

Bonus - Wiki compilé : Au-delà de la mémoire courte, un cron quotidien à 6h extrait des patterns structurés depuis SQLite vers un vault Obsidian (people, projects, decisions), buildé en site statique via Quartz. La mémoire courte reste la source de vérité verbatim. Le wiki est la couche compilée long-terme.

Chantier 3 : pipeline email cron-safe

Le tri de mails, cas d'usage n°1 dans la V1, a été entièrement réécrit en trois phases découplées pour tourner en cron sans aucune dépendance MCP.

• Phase 1 (bash/python) : collecte via gws +triage, dédup par threadId

• Phase 2 (claude -p --haiku) : classification ACTION/INFO/SPAM + summary + suggestedAction

• Phase 3 (bash/python) : apply labels, archive si autonomous, recap Telegram

Cette réécriture a trois avantages :

• Cache de classifications. Les threads déjà classifiés par Haiku ne sont pas reclassifiés à chaque run. Un hash des messageIds invalide le cache quand le thread a bougé. La majorité des runs journaliers n'appellent Haiku que sur 2 ou 3 threads, pas les 25 de mon inbox.

• Les actions se font au niveau thread, jamais au niveau message. 

• Auto-move SPAM en calibration. Par défaut les SPAM sont déplacés directement, même en phase calibration. Les faux positifs sont récupérables et le gain d'attention est disproportionné.

Les grandes évolutions fonctionnelles

Tri email en pilote quasi automatique

Le triage tourne en LaunchAgent quatre fois par jour en semaine. Il lit tous les mails encore dans mon inbox (règle : tant que je n'ai pas archivé, Life considère que je n'ai pas traité), les classe en ACTION, INFO ou SPAM, déplace automatiquement les SPAM, et m'envoie un recap structuré sur Telegram. Je réponds avec des numéros : "3, 5 archive, 7 agenda". Derrière, Life exécute.

Nouveauté récente : Haiku propose maintenant une action concrète pour chaque mail ACTION. Task, agenda, draft, ou rien. Un exemple vécu cette semaine : je reçois un mail d'une expert-comptable qui a besoin d'une évaluation de portefeuille au 30 avril. Haiku propose de lui-même un event calendrier le 25 avril intitulé "Demander éval au 30/04", avec un backward-planning de cinq jours. Je valide d'un mot, c'est dans mon agenda. Je n'ai pas eu besoin d'y réfléchir.

Intégration cross-channel : là où ca devient bluffant

Plus que sur des cas isolés, Life devient vraiment différent d'un agent IA classique sur des enchaînements. 

Exemple 1 : Je sors d'un entretien stratégique. Un partenaire me ping sur WhatsApp : "alors, comment ca s'est passé ?". Je dis à Life d'aller chercher le transcript Granola de la réunion et de me drafter une réponse. Trente secondes plus tard, j'ai sur Telegram : un résumé de 250 mots distillé par un sous-agent Haiku qui a lu le transcript brut de 8 000 mots, plus un draft WhatsApp en anglais, parce que Life est allé voir que mes derniers échanges avec cette personne sur Slack étaient en anglais, et a adapté la langue. Je fais un petit tweak sur une nuance, et Life réécrit.

Exemple 2 : Je poste un update stratégique dans un canal Slack privé sur un sujet de recrutement. Dans la foulée je dis à Life : "retrouve-moi le dernier échange avec la dirigeante de X". Il retrouve un fil de mail dormant depuis mars, me signale que je ne lui avais jamais répondu, propose un draft qui anticipe la suite logique du sujet Slack, et suggère de mettre en copie la responsable recrutement interne. Les trois sources ont été combinées dans un seul draft cohérent.

Exemple 3 : Un matin, je découvre un incident administratif chez moi qui impacte trois dossiers en parallèle : un banquier, un syndic, une présidente de conseil syndical. Je dicte le contexte une fois. Life comprend les trois dossiers, me drafte trois messages d'excuses cohérents entre eux mais chacun dans son registre. Vouvoiement formel pour le banquier, cordial pour le syndic, informatif avec mise en contexte pour la présidente. Et ce sans que je réexplique quoi que ce soit.

C'est ca, le vrai saut, cette capacité à tenir le fil entre plusieurs canaux, plusieurs registres, et plusieurs échelles de temps.

What's next

Quelques chantiers qui me semblent évidents pour la suite.

• WhatsApp en entrée. Pour l'instant Life lit Gmail, écoute Slack et Granola, et reçoit mes messages via Telegram. Il ne lit pas mon WhatsApp, alors que c'est un canal clé pour moi. Il existe des MCPs non-officiels basés sur whatsmeow qui permettraient la lecture. Le risque de ban de compte est non-nul, mais le jeu en vaudra probablement la chandelle. À explorer proprement.

• LinkedIn via Unipile. Pour qu'il puisse lire mes DMs pros et poster sous mon contrôle.

• Plus de skills, mieux structurés. Je suis à 13 skills. Certains setups publics que j'admire sont à 60+. Je n'ai pas besoin de tous les réinventer - certains peuvent être repris directement, notamment ceux de Kepano, le fondateur d'Obsidian, qui a publié ses skills officiels pour markdown, bases et JSON canvas.

• Frontmatter et backlinks dans mon vault Obsidian. Aujourd'hui mes pages sont plates. Les connecter explicitement démultiplierait la valeur du wiki.

• Sortir Life du prototype. Pour l'instant c'est monté sur mon Mac perso, via tmux, avec un LaunchAgent et une bonne dose de scotch. Ca marche, mais c'est fragile. À terme, il faudra probablement virer tout ou partie sur une infra dédiée.

Ce que je retiens vraiment

Si je devais garder un seul enseignement après ces quelques semaines, c'est que la valeur d'un agent ne vient pas de ses capacités techniques individuelles mais de la continuité de contexte.

Que Claude réponde bien à une question, so what ? N'importe quel chatbot sait le faire. Que Claude se souvienne que tu as promis quelque chose la semaine dernière, qu'il adapte la langue selon l'interlocuteur, qu'il reconnaisse un expéditeur récurrent et propose la bonne action sans qu'on lui demande, là c'est autre chose.

Le travail à faire est globalement ingrat. Optimiser les tokens, remplacer un MCP par un CLI, documenter un feedback, nettoyer un cache.... Ça ne fait pas un sujet très sexy pour un post LinkedIn, mais c'est ce qui transforme un outil en extension de soi. De mon côté, je vais continuer à faire progresser Life, et j'espère avoir des choses à vous raconter bientôt !