Couloirs d’agents : donnez à chaque agent IA nommé sa propre file d’attente

Un couloir d’agent est une file d’attente nommée dans votre compte Done (Claude, Instinct, Muse, ou le nom que vous donnez à vos agents). Une tâche épinglée à l’un d’eux n’apparaît que dans le list_my_tasks, le next_task et le list_triggers de cet agent, jamais dans ceux d’un autre. Configurez-le depuis Réglages → Accès des agents → Liste des agents : nommez chaque agent, puis associez un identifiant à chaque nom (un jeton MCP supplémentaire, ou une application connectée que vous renommez). Done achemine alors chaque prise en charge selon l’identifiant qui fait réellement la demande, et non selon ce que le client dit de lui-même.

Comment Done sait-il quel identifiant correspond à quel agent ?

Par le nom de l’identifiant lui-même, jamais par un argument d’outil. Le couloir d’un appelant vient du nom de son jeton MCP (défini quand vous générez un jeton MCP supplémentaire depuis le panneau Compte) ou du libellé de sa connexion OAuth (renommez un connecteur claude.ai ou Claude Desktop depuis Réglages → Accès des agents → Applications connectées), comparé à la liste des agents sans tenir compte de la casse. Un client peut mettre ce qu’il veut dans l’argument agent d’un outil, mais il ne peut rien mettre dans un identifiant qu’on lui a délivré. C’est précisément pour cela que la correspondance porte sur l’identifiant et non sur l’argument : une tâche épinglée au couloir d’Instinct ne peut pas être prise en charge par quelque chose qui se contente de prétendre être Instinct.

Que se passe-t-il pour un identifiant absent de la liste des agents ?

Il travaille dans le couloir de l’agent par défaut : la première entrée de la liste, sauf si vous avez déplacé ce rôle ailleurs. C’est aussi ce qu’obtient un jeton à accès complet sans nom, et toute exécution lancée avant que vous n’ayez une liste d’agents. Rien ne casse, l’identifiant n’est simplement pas distingué de l’agent par défaut. Un compte sans aucune liste d’agents se comporte exactement comme avant : tous les agents partagent une seule file, list_agents renvoie une liste vide, et rien de tout cela ne vous gêne tant que vous ne l’activez pas.

Épingler une tâche à un agent précis

Dans l’application, le sélecteur Attribuée à de la fenêtre de tâche propose Moi ainsi que chaque agent de la liste dès que vous en avez ajouté au moins un. Choisissez un nom, et le champ delegate de la tâche est renseigné en même temps que son responsable. Par MCP, create_task accepte un argument agent, mais uniquement vers votre propre couloir : une tâche que vous créez arrive toujours dans votre propre file, jamais dans celle d’un autre. Un agent n’a donc aucun moyen d’envoyer discrètement un travail tout neuf à un collègue au moment de la création. Faire passer un travail existant à quelqu’un d’autre est une action distincte et délibérée.

Passer le relais à un autre agent : handoff_task

handoff_task transfère une tâche que vous détenez à un autre agent nommé, en cours de route : vous avez constitué la liste de prospects, c’est maintenant à Instinct de les contacter. La prise en charge de la tâche est libérée, elle repasse à not_started pour que le next_task de l’agent destinataire la récupère, et tout ce qui la concerne la suit : notes, critères d’acceptation, livrables, tout le fil de commentaires. Votre argument note est lui aussi publié dans ce fil. Dites donc ce qui est fait, ce qui reste à faire et où se trouve votre résultat avant de passer le relais : l’agent destinataire n’a aucun autre moyen de le savoir. Un effet secondaire voulu : agent_ok repasse à false à chaque passation, parce que la confiance qu’un humain a accordée pour votre moitié du travail ne s’étend pas à la moitié de l’agent suivant. La tâche s’arrête à propose_completion jusqu’à ce qu’un humain la réactive pour celui qui la détient désormais.

En quoi cela diffère de la file partagée de la flotte dans Done

C’est un autre axe que celui que traitent déjà fleet_status et le retrait atomique de next_task. Sans couloirs, tous les agents se disputent la même file, et la seule garantie est que deux d’entre eux ne peuvent pas saisir la même tâche en même temps. Les couloirs ajoutent une seconde garantie, indépendante de la première : dans quelle file la tâche se trouve. Vous pouvez utiliser à la fois des couloirs et une flotte de plusieurs agents (le next_task de chaque couloir reste atomique face aux autres identifiants qui partagent ce couloir), mais la plupart des comptes qui adoptent les couloirs veulent un travail réparti selon l’agent qui doit le faire, pas seulement la garantie d’éviter les collisions.

Qui peut modifier la liste des agents ?

Seulement un humain, depuis l’application. Les routes de la liste des agents n’acceptent que la session par cookie, et il n’existe aucun outil MCP qui crée, renomme ou supprime un agent. C’est voulu : un agent capable de modifier la liste dont il fait partie pourrait s’attribuer du travail. list_agents est en lecture seule pour la même raison. Un agent peut voir la liste et son propre couloir, jamais modifier l’un ou l’autre.

Faut-il une offre payante pour cela ?

Non. Il n’y a aucune vérification d’offre dans les routes de la liste des agents ni dans le parcours du jeton restreint dont provient un identifiant nommé. Nommer des agents et utiliser des couloirs fonctionne donc aujourd’hui avec n’importe quelle offre.