Imaginons une équipe avec quarante conversations ouvertes. Dans l’une, quelqu’un demande à un agent de préparer une proposition commerciale. Dans une autre, une collègue demande une estimation de livraison. Une troisième personne vérifie si la même fonctionnalité peut sortir ce mois-ci.
Chaque conversation commence par un rappel. Voici le client. Voici ce que nous avons promis. Voici la décision prise hier. Les agents se mettent au travail, mais chacun voit une partie différente. Quelqu’un finit par remarquer que la proposition promet une date déjà écartée dans la discussion technique.
Puis une Task se termine. Sa conversation devient silencieuse. Une semaine plus tard, une autre personne commence un travail lié et explique à nouveau le contexte.
En construisant nos agents, nous revenions sans cesse à cette scène. Nous voulions que le travail suivant parte de ce que l’équipe avait déjà appris. Cela nous a conduits à une conception à session unique : une conversation principale persistante, avec des Workers indépendants pour exécuter les différentes Tasks.
Les sous-agents aident à répartir le travail. La session unique répond à une autre question : où reste la compréhension de ce travail au fil du temps ? Nous utilisons les deux. La conversation principale assure la continuité de l’équipe ; les Workers donnent à chaque travail son espace d’exécution.
De la personne au canal, puis à l’équipe
Poke a donné à l’agent personnel un point d’ancrage simple : une personne, une conversation (septembre 2025). Il reliait les e-mails, le calendrier et les fichiers d’une personne à une conversation textuelle. Une demande de brouillon ou de déplacement de réunion pouvait partir du même endroit que la précédente. Au fil de la journée, la conversation devenait un lieu où revenir. La relation personnelle était au centre de l’expérience et nous offrait un exemple concret de continuité entre plusieurs travaux.
Claude Tag a placé un Claude dans un canal (23 juin 2026). Chacun pouvait mentionner le même agent, voir son travail et reprendre là où un collègue s’était arrêté. Claude mémorisait des informations pertinentes au fil du temps et utilisait les outils autorisés par les administrateurs. L’annonce décrivait aussi l’apprentissage à partir d’autres canaux et sources, avec les permissions nécessaires. La conversation partagée nous intéressait : on pouvait déléguer là où l’on discutait déjà du travail. Notre propre conception fait de la conversation principale de l’équipe le point de retour des discussions et des Tasks qui l’alimentent.
Nous avons choisi d’explorer une équipe, une conversation. Le périmètre suit le travail de l’équipe à travers ses discussions. Une décision de livraison peut éclairer la proposition, même si ces travaux ont commencé à des endroits différents.
Le 28 avril 2026, nous avons publié notre premier article sur Bridge, notre produit précédent. Cette partie de notre exploration vient après Poke et avant Claude Tag. Nous avons poursuivi ce travail dans notre produit actuel, Comma (1er octobre 2026), où cette conception fonctionne aujourd’hui.
DeepSeek Harness a présenté une autre exploration le 31 octobre 2026 : Super-agent. Son travail proactif dans les conversations de groupe va dans le même sens : transférer la coordination des personnes au système. Ce prototype de recherche suit sa propre conception.
L’article de conception de DeepSeek, §8.4, laisse deux questions ouvertes : une compromission du cloud ou une injection de prompt qui expose les appareils connectés, et la fuite d’identifiants par le contexte du modèle. Notre réponse en fonctionnement pour le contenu est IFC : déclarer les sources, vérifier les lecteurs de la destination, refuser les envois interdits et demander une autorisation humaine ciblée si nécessaire.
Les identifiants suivent un autre chemin. Le modèle nomme une référence ; la couche d’exécution résout et injecte sa valeur sans la renvoyer au modèle.
Ce que l’équipe conserve
Prenons une nouvelle collègue qui rejoint le travail sur la proposition. Elle arrive dans la même conversation principale que le reste de l’équipe. Elle peut consulter les décisions partagées, demander pourquoi une date a changé et poursuivre sans réclamer trois résumés à trois personnes. Son appartenance à l’espace de travail lui donne accès à cette conversation ; les documents derrière une décision conservent leurs propres permissions.
Une Task terminée garde son résultat et son historique. L’équipe a peut-être découvert qu’un client exige un format d’export inhabituel. Le rapport revient au Router et une proposition ultérieure peut se référer au constat et à sa source. La Task est finie, mais l’équipe garde un endroit où retrouver ce qu’elle a appris.
Le travail parallèle rend ce chemin de retour important. Un Worker peut lire les exigences du client pendant qu’un autre étudie une limite technique. Une condition importante peut disparaître si les constats passent par plusieurs récits successifs. Chaque Task rapporte ses découvertes avec leurs sources. Le Router les reçoit dans le même contexte principal.
Cela nous a donné une raison de diviser le harnais d’agents en deux rôles. L’un suit la conversation continue de l’équipe. Les autres réalisent les travaux individuels.
Comment le Router et les Workers collaborent
Nous attribuons à chaque espace de travail un Router résident. Il conserve le contexte principal de l’équipe et suit les demandes, les changements de décision et les résultats. Une demande concernant la proposition arrive dans le même contexte que la discussion de livraison déjà engagée. Chaque message entrant porte l’identité de sa conversation et de son message d’origine. Le Router partage le contexte entre discussions tout en conservant l’origine de chaque entrée.
Le Router confie un travail défini à un Worker. Chaque Task ouvre une nouvelle session de Worker avec ses instructions et sa transmission. Les historiques des autres Workers restent dans leurs sessions respectives. Plusieurs Workers peuvent étudier des questions différentes en parallèle.
Nous définissons chaque Task avec un objectif, le contexte pour le poursuivre et un livrable attendu. « Étudie ce client » laisse trop de choses implicites. « Vérifie ses exigences d’export et propose un format, avec les sources et les questions ouvertes » donne au Worker un travail qu’il peut terminer et au Router un résultat exploitable.
Supposons que la proposition nécessite une vérification d’export et une estimation de livraison. Nous pouvons les confier à des Workers différents. L’un rend les exigences du client. L’autre rend une estimation et ses hypothèses. Le Router ramène les résultats dans la conversation principale, où l’équipe peut décider. Le travail terminé a un chemin de retour.
Chaque réponse visible est un envoi explicite, y compris dans la conversation principale. Le Router nomme la destination et passe les contrôles de cette destination. La sortie du modèle et la fin d’un tour ne publient pas de réponse. La même règle s’applique lorsqu’un Worker rapporte un résultat ou s’adresse à un autre participant. Lire les documents d’une Task donne au Worker du contexte ; l’envoi reste une action distincte.
Contrôle des flux d’information
Les Tasks parallèles réunissent des sources aux publics différents. Chaque envoi déclare les sources utilisées. Le contrôle des flux d’information, ou IFC, vérifie que les lecteurs de la destination peuvent lire ces sources.
Lorsque l’application des contrôles est activée, un envoi refusé renvoie une raison. L’agent peut retirer les éléments restreints et réessayer, ou demander l’autorisation humaine nécessaire pour ce périmètre. Une nouvelle tentative doit modifier le contenu ainsi que la déclaration des sources.
IFC donne à l’équipe une étape vérifiable entre la préparation d’une réponse et son partage.
Revenons à la proposition. Le Router peut présenter l’estimation à l’équipe, demander la décision encore attendue et envoyer la réponse convenue par le canal approprié. Le travail du Worker a un périmètre délimité. La conversation de l’équipe se poursuit à travers cette transmission.
Une nouvelle Task ouvre une nouvelle session de Worker. Quand nous changeons de session, nous transmettons le travail inachevé et ses références à la suivante. L’équipe a toujours besoin de pouvoir revenir à ses décisions antérieures.
Ce que l’équipe apprend ensemble
Les procédures réutilisables deviennent des skills partagées par le groupe : des instructions et des ressources modifiables. L’agent créateur contrôle les modifications effectuées par les agents. Les autres peuvent utiliser la skill sans la réécrire ; une skill intégrée en lecture seule peut être copiée pour être adaptée. Les sessions reçoivent le catalogue de leur périmètre et ouvrent les instructions pertinentes.
Le Router entretient une mémoire durable des personnes, des environnements, des faits généraux et des épisodes datés. Il la lit ou la recherche à la demande. Les Workers ordinaires utilisent les transmissions des Tasks ; les Triage Workers affectés ont un accès en lecture lié à la source. L’écriture de la mémoire revient au Router.
Lorsqu’il est activé, Condensed Workspace donne à chaque session interne de Router et de Worker la même courte liste de faits actuels du groupe. Le propriétaire de l’espace de travail peut la modifier directement.
Les mises à jour des agents reçoivent un contrôle consultatif de leur pertinence comme faits actuels utiles aux autres agents. Les révisions et le dernier auteur sont enregistrés. Le propriétaire peut corriger ou supprimer des affirmations, pour rendre les hypothèses partagées visibles et modifiables. Une mise à jour refusée peut être retentée avec son identifiant de refus pour passer explicitement outre le contrôle.
Le coût d’une conversation continue
Cette organisation met la session principale sous pression. Les Workers peuvent travailler en parallèle, mais le Router doit encore réunir leurs résultats. Une nouvelle demande peut arriver pendant qu’il traite la précédente. Pour les personnes, cela reste une file d’attente, quel que soit le nombre de Workers disponibles.
Nous travaillons encore sur les files séquentielles. Déléguer une longue enquête donne au Router plus de place pour répondre, mais les décisions liées ont toujours besoin d’un ordre. Dans la proposition, quelqu’un doit fixer la date de livraison avant que la promesse finale parte. Une conversation partagée rend cette dépendance plus visible et donne au Router davantage de responsabilité pour faire avancer le travail.
L’historique a son propre coût. Chaque Task terminée ajoute quelque chose qui pourra servir plus tard, ainsi que beaucoup d’éléments qui ne serviront plus. À mesure que l’historique grandit, retrouver la bonne décision et ses raisons demande plus de travail.
Nous voulons retrouver une ancienne décision sans demander à un collègue de reconstruire toute la discussion. Ses raisons aident l’équipe à reconnaître quand elle doit changer.
Voilà où en est notre exploration. Nous avons choisi une conversation principale partagée parce que les équipes reviennent au même travail à travers différentes personnes et différentes Tasks. Quand quelqu’un ouvrira une discussion liée, nous voulons que les efforts précédents de l’équipe soient toujours là.
