Plusieurs agents communicant via une boîte mail fichier

Quelle différence entre Subagent et Teammate ?

Le subagent de S04 est simple et radical : spawn → exécution → retour du résumé → destruction. Ponctuel, sans nom, sans communication bidirectionnelle entre parent et enfant.

Le teammate de s09 est un agent indépendant avec un nom, qui peut être réveillé à plusieurs reprises et qui sait envoyer et recevoir des messages :

subagent (s04):  spawn -> execute -> return -> destroyed
teammate (s09):  spawn -> work -> idle -> work -> ... -> shutdown

Les deux mécanismes ont des usages différents :

• Le subagent convient pour « faire une exploration précise » (par exemple, revue d'une PR).
• Le teammate convient pour « assumer un rôle de façon durable » (par exemple, un reviewer permanent qui est appelé à chaque nouveau commit).

La boîte mail, c'est un fichier JSONL

Comment les membres de l'équipe communiquent-ils ? s09 utilise le mécanisme le plus basique qui soit : des fichiers JSONL en append-only.

.team/
  config.json          # annuaire de l'équipe
  inbox/
    alice.jsonl        # tous les messages pour alice sont appendés ici
    bob.jsonl
    lead.jsonl

Envoyer = open("alice.jsonl", "a").write(msg) ; lire = parcourir tout le fichier, parser le JSONL, puis truncate (sémantique drain).

Pourquoi des fichiers et non une queue en mémoire ? Les fichiers sont naturellement persistants. Redémarrage d'un agent, crash du processus, même redémarrage de la machine — les messages sont toujours là. Et comme ils sont lisibles et « greppables », le débogage est un plaisir.

Voir le parcours d'un message de lead à alice

Le widget ci-dessous vous permet d'envoyer un message à alice et de suivre chaque étape sur le système de fichiers.

5 types de messages

s09 définit 5 types de messages (VALID_MSG_TYPES), mais n'en implémente que les deux premiers — les trois suivants sont ajoutés dans la leçon s10 sur les protocoles :

• message — message textuel ordinaire.
• broadcast — envoyé à tous les teammates sauf soi-même.
• shutdown_request / shutdown_response — demande/réponse d'arrêt gracieux (s10).
• plan_approval_response — approbation de plan (s10).

Pourquoi les déclarer sans les implémenter ? Parce que s09 veut laisser le « protocole » ouvert : les types de messages sont une énumération, en ajouter un ne demande qu'une entrée dans le dictionnaire et un handler dans le routeur _exec.