Le problème
Le travail asynchrone s’arrête aux frontières. Le prochain agent (ou le même agent, le lendemain matin) doit reconstruire le périmètre, la logique et les risques restants à partir des messages de commit, des notes éparpillées et d’un historique Slack vague. La majeure partie de la session reprise est consacrée à la relecture plutôt qu’au travail.
L’approche brainclaw
- Conserver l’état comme un handoff, et non comme une note.
bclaw_create(entity='handoff', data=...)écrit un instantané immuable lié au plan actif, au diff git depuis le début de la session et aux claims ouverts. Le prochain agent obtient l’état complet en une seule lecture. - Définir les pré/post-conditions. Un handoff inclut “avant de reprendre, vérifier que X est toujours vrai” et “après que ce travail soit fait, le plan devrait atteindre l’état Y”. Le prochain agent vérifie la condition d’entrée avant de retoucher le code — aucune réinitialisation surprise.
- Capturer les observations en ligne.
bclaw_write_noteenregistre les petits détails du type “J’ai remarqué Z en faisant Y” qui ne méritent pas une décision mais qui sont importants lors de la reprise. Capture rapide, sans friction. - Reprendre avec le delta, et non avec le dépôt complet.
bclaw_context(kind='delta', since=<previous_session_id>)montre ce qui a changé depuis la session précédente — au lieu de relire l’état complet du projet chaque matin.
Ce qui change
La frontière entre les sessions cesse d’être une zone de perte de contexte. Un développeur solo qui reprend le lendemain matin voit ce qu’il a lui-même laissé inachevé. Un coéquipier qui prend en charge une fonctionnalité inachevée voit la même chose.
Là où cela brille le plus
Les équipes distribuées. Lorsque l’agent effectuant le handoff et l’agent qui le reçoit se trouvent dans des fuseaux horaires différents, la coordination asynchrone est le flux de travail — et le coût d’un mauvais handoff est un décalage d’un fuseau horaire complet.