Agents externes

Tale fournit des agents externes intégrés — Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi et OpenClaw — dont le tour entier s'exécute dans un bac à sable isolé. Au lieu de la boucle de chat habituelle, ton message est confié à cet agent de code, qui vit dans un conteneur neuf, modifie des fichiers, lance des commandes et rend compte. Tu lui parles directement dans le chat, et il conserve le même répertoire de travail et la même conversation d'un tour à l'autre, de sorte qu'une instruction de suivi comme « ajoute maintenant un test pour ça » reprend là où il s'était arrêté.

C'est la même idée que de lancer un tel outil sur une machine distante, sauf que la machine est un bac à sable géré que l'espace de travail contrôle. Cette page explique comment les utiliser, ce que le bac à sable peut atteindre ou non, et comment ils sont facturés.

Parler à un agent de code

Choisis Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi ou OpenClaw dans le sélecteur de chat et décris une tâche en langage clair — « écris un petit outil CLI en Python et teste-le », « clone ce dépôt et corrige le bug de l'issue #42 ». L'agent travaille dans son bac à sable : il planifie, écrit des fichiers, lance des commandes shell et installe des paquets au besoin, puis répond avec ce qu'il a fait. Pendant qu'il travaille, tu vois un indicateur de réflexion ; la réponse arrive quand le tour se termine.

Inutile d'attendre la fin d'un tour. Le champ de saisie reste ouvert pendant que l'agent travaille : tout ce que tu envoies patiente dans la zone Messages en attente au-dessus du champ de saisie, puis est transmis à l'agent en cours à sa prochaine occasion. Claude Code les prend en plein tour, à la prochaine frontière d'outil — une correction comme « utilise pnpm, pas npm » arrive donc pendant que le travail se poursuit. Cursor, OpenCode, Codex, Pi, OpenClaw et les autres runtimes one-shot vident la file aux frontières de tour. Le message n'entre dans le fil qu'à ce moment-là, exactement à l'endroit où il a agi ; d'ici là tu peux le retirer (le × sur sa ligne). Appuyer sur Stop termine le tour en cours ; les messages encore en attente sont envoyés automatiquement quelques secondes plus tard comme tour suivant, avec le contexte de l'agent intact.

Chaque fil de discussion est adossé à une session de bac à sable persistante. Les messages de suivi réutilisent la même session et les mêmes fichiers, et l'agent reprend son raisonnement antérieur au lieu de repartir de zéro. Comme la session appartient au fil, le fil garde aussi son agent : le sélecteur reste épinglé dessus, et changer d'agent ailleurs ne redirige jamais ce fil — ouvre une nouvelle discussion pour en utiliser un autre. Supprimer ou archiver le fil démonte le bac à sable et libère ses ressources.

Ce que le bac à sable peut atteindre

Le bac à sable démarre avec un répertoire de travail vide et est verrouillé par défaut. Les fichiers et dossiers que tu épingles avec @ dans ton message sont livrés dans le bac à sable sous /user/uploads/, si bien que l'agent ouvre les vrais octets au lieu de travailler à partir d'un extrait de récupération. Le trafic réseau sortant est refusé sauf pour une petite liste d’autorisation (registres de paquets et GitHub), de sorte que l'agent peut installer des dépendances et cloner des dépôts publics mais ne peut pas atteindre des hôtes arbitraires. Par défaut, le modèle est atteint via la passerelle de l'espace de travail, jamais via une clé de fournisseur brute — le bac à sable ne détient qu'une clé éphémère et limitée par un budget pour ce tour. Ce comportement par défaut est le mode d'identifiants géré de l'agent ; l'alternative apporte tes propres identifiants, traitée plus bas, place au contraire délibérément ta propre clé de fournisseur dans la boîte.

Au-delà de ce verrouillage, l'agent peut atteindre n'importe quelle intégration que ton organisation a connectée — chercher sur le web via Tavily, appeler une API, interroger une base de données — tant que cette intégration est liée à l'agent. Tu les lies comme pour n'importe quel autre agent : ouvre l'onglet Outils de l'agent et sélectionne-les sous Intégrations liées. L'identifiant n'entre jamais dans le bac à sable ; quand l'agent appelle une intégration, la requête repart vers Tale, qui exécute l'appel avec l'identifiant stocké et ne renvoie que le résultat — un conteneur compromis ne peut donc pas lire tes clés. Une opération d'écriture ne s'exécute pas en silence : elle apparaît comme une carte d'approbation dans le chat et se déroule une fois que tu l'approuves.

Les données de l'espace de travail lui-même empruntent le même chemin relayé. Sur ce même onglet Outils, tu peux aussi accorder des outils de la plateforme — recherche dans les connaissances, parcours et lecture de documents, enregistrement de fichiers dans le hub de documents — et l'agent les appelle depuis le bac à sable pendant qu'il travaille. Chaque appel s'exécute sur la plateforme dans le périmètre de connaissances de l'agent et ne renvoie que le résultat ; le bac à sable ne détient donc aucun identifiant de plateforme non plus, et un enregistrement dans le hub fait apparaître la même carte d'approbation que toute autre écriture. Les outils non liés ne peuvent pas être appelés, et un agent en mode « apporte tes propres identifiants », qui tourne sans clé de session, n'a pas de pont d'outils du tout.

GitHub est l'exception qui place aussi un jeton dans le bac à sable, parce que git et la CLI gh en ont besoin localement : connecte GitHub sous Intégrations et lie-le à l'agent, et la session reçoit un jeton à portée limitée pour que l'agent puisse cloner, pousser et ouvrir des pull requests en ton nom. Tous les identifiants — le jeton GitHub dans le bac à sable comme ceux qui sont relayés — sont limités à la session, audités à chaque appel et révoqués à la fin de la session.

Identifiants gérés et apportés par toi

La façon dont l'agent atteint son modèle est un choix propre à chaque agent, défini dans l'onglet Instructions de l'agent, sous Identifiants. Trois backends d'identifiants existent ; l'interface les nomme selon le runtime de l'agent.

Géré par la passerelle (Claude Code, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi et OpenClaw, géré) est le mode par défaut pour ces runtimes. La plateforme forge une clé virtuelle éphémère pour le tour, achemine l'agent par sa passerelle, applique les modèles autorisés de l'agent depuis le catalogue Fournisseurs, mesure l'utilisation et applique les plafonds de dépense de l'organisation. Le bac à sable ne détient jamais de vraie clé de fournisseur. Les tours gérés de Hermes et de Codex passent par une route de passerelle compatible OpenAI (OPENAI_BASE_URL plus la clé virtuelle de session dans le bac à sable ; Codex y parle l'API Responses d'OpenAI) ; les tours Gemini CLI gérés par la route compatible Google GenAI de la passerelle (GOOGLE_GEMINI_BASE_URL plus la clé virtuelle de session comme GEMINI_API_KEY) ; les tours Pi gérés eux aussi par la route compatible OpenAI, câblée comme une configuration de fournisseur Pi propre au tour qui référence la clé virtuelle de session depuis l'environnement (le fichier de configuration ne contient jamais la clé) ; les tours OpenClaw gérés par la route compatible OpenAI de la passerelle, via une configuration de fournisseur générée à chaque tour.

Géré par l'environnement (Cursor, géré) s'applique aux runtimes qui s'authentifient avec une clé API que tu stockes sur l'agent, pas via la passerelle. Ouvre la page Environnement de l'agent et définis CURSOR_API_KEY (ou la clé que le runtime déclare). Le modèle est un identifiant runtime que tu saisis dans la liste Modèles des Instructions — composer-2.5, par exemple — et non une entrée de catalogue. Ces tours ne sont pas mesurés dans l'Analyse d'utilisation ; la facturation relève de ton compte Cursor.

Apporte tes propres identifiants (BYO) retire la plateforme du chemin de la requête pour les runtimes pris en charge (Claude Code, Cursor, Gemini CLI, Codex, Pi et OpenClaw). OpenCode est géré uniquement — sa configuration runtime pointe vers la passerelle de la plateforme et s'authentifie avec la clé virtuelle de session ; le BYO n'est pas disponible pour les agents OpenCode. Aucune clé virtuelle n'est forgée ; l'agent s'authentifie avec les identifiants que tu stockes sous Variables d'environnement et secrets et atteint directement le fournisseur. Le modèle devient un identifiant runtime brut que tu saisis tel quel plutôt qu'une entrée de catalogue. Comme la passerelle est contournée, la liste de modèles autorisés, les plafonds de dépense et la mesure d'utilisation de l'organisation ne s'appliquent pas aux tours BYO — la facturation et les limites passent à ton propre compte de fournisseur. Faire passer un agent du mode géré au mode BYO efface ses modèles de plateforme enregistrés lorsqu'il s'agissait de références de catalogue ; tu ressaisis les identifiants bruts.

C'est aussi un déplacement de la frontière de confiance. En mode géré par la passerelle, le bac à sable ne détient qu'une clé de passerelle limitée par un budget ; en mode géré par l'environnement ou BYO, ton véritable identifiant de fournisseur est injecté dans l'environnement du bac à sable — la même posture que le jeton GitHub dans le bac à sable — de sorte que tout code que l'agent exécute dans la boîte peut le lire. C'est intentionnel : c'est ta boîte et ton identifiant. Configurer un agent est déjà une action privilégiée, si bien que le commutateur par agent est le seul contrôle ; il n'y a pas de bascule distincte au niveau de l'organisation.

Moteurs et modèles

Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi et OpenClaw sont des entrées distinctes dans le sélecteur de chat (ou des agents que tu configures avec agentKind défini en conséquence).

Pour Claude Code, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi ou OpenClaw géré par la passerelle, le modèle provient de la liste des modèles pris en charge de l'agent dans le catalogue Fournisseurs — choisis-le dans le sélecteur de modèle. Claude Code et OpenCode sont livrés avec Claude Fable 5 par défaut, et la capacité de Fable est rationnée : une requête signalée par ses classificateurs de sécurité, un modèle surchargé ou un quota Fable épuisé ne fait pas échouer le tour — la session bascule automatiquement sur le modèle de repli défini dans l'entrée du catalogue, Claude Opus 4.8 (Claude Code uniquement ; OpenCode utilise l'identifiant de modèle de passerelle que tu as choisi). Hermes Agent, Pi et OpenClaw sont livrés avec Claude Sonnet 4.6 et Claude Opus 4.8, Gemini CLI avec Gemini 3 Pro et Gemini 3 Flash, Codex avec GPT-5.5 et GPT-5.5 Pro ; tous exécutent tout le tour sur le modèle choisi — sans repli automatique. Une particularité d'OpenClaw : son runtime rend compte en mode headless à la fin du tour, le chat affiche donc la réponse finale et l'utilisation, pas une chronologie outil par outil.

Pour Cursor géré par l'environnement (et BYO sur tout runtime), l'éditeur Modèles des Instructions accepte des identifiants runtime de ton compte — exécute agent models dans une session de bac à sable pour voir ce que ton abonnement expose. Laisse la liste vide pour que le runtime choisisse son défaut (Auto). Le sélecteur de modèle du chat affiche un indicateur en lecture seule — le nom court de l'identifiant configuré, ou Modèle par défaut quand la liste est vide — plutôt que le menu déroulant du catalogue.

Un agent BYO Hermes Agent utilise les identifiants que tu stockes sous Variables d'environnement et secrets — le plus souvent OPENROUTER_API_KEY, OPENAI_API_KEY ou ANTHROPIC_API_KEY, selon ton fournisseur. Définis le modèle sur un identifiant de style Hermes/OpenRouter (par exemple openrouter:anthropic/claude-sonnet-4.6).

Un agent BYO Gemini CLI utilise tes propres identifiants Google stockés sous Variables d'environnement et secrets — GEMINI_API_KEY pour l'API Gemini, ou GOOGLE_API_KEY avec GOOGLE_GENAI_USE_VERTEXAI=true pour Vertex AI. Saisis des identifiants de modèle Google bruts (par exemple gemini-3.1-pro-preview) ; les valeurs par défaut livrées au format catalogue sont traduites à l'exécution en leurs identifiants natifs Google.

Un agent BYO Pi utilise les identifiants que tu stockes sous Variables d'environnement et secrets — le plus souvent OPENROUTER_API_KEY, ANTHROPIC_API_KEY ou OPENAI_API_KEY, selon ton fournisseur. Définis le modèle sur un identifiant du propre catalogue de Pi (pi --list-models dans une session de bac à sable) — par exemple anthropic/claude-sonnet-4.6 avec une clé OpenRouter ; les valeurs par défaut livrées au format catalogue sont traduites à l'exécution en ces identifiants de style OpenRouter. Pi n'a pas d'outils web intégrés ; les informations externes passent par les intégrations liées ou par ce que curl atteint sur la liste d'autorisation réseau du bac à sable.

Un agent BYO OpenClaw utilise les identifiants que tu stockes sous Variables d'environnement et secrets — ANTHROPIC_API_KEY, OPENAI_API_KEY ou OPENROUTER_API_KEY, selon ton fournisseur. Définis le modèle sur une référence OpenClaw provider/model (par exemple anthropic/claude-sonnet-4-6), ou laisse-le vide pour le défaut du runtime.

Un agent BYO Codex utilise l'OPENAI_API_KEY que tu stockes sous Variables d'environnement et secrets et parle directement à l'API d'OpenAI. Les références de catalogue livrées sont traduites via le nativeModelId de l'entrée (gpt-5.5, par exemple) ; les identifiants que tu saisis toi-même passent inchangés.

Un agent BYO Claude Code saisit des identifiants Anthropic bruts — claude-opus-4-20250514, par exemple — par ordre de priorité. Les agents pack livrés qui portent encore des références de catalogue sont traduits à l'exécution via le nativeModelId de chaque entrée ; les identifiants que tu as saisis toi-même passent inchangés.

Coût et budget

Les tours d'agents externes peuvent être longs et appeler le modèle de nombreuses fois ; ils coûtent donc plus qu'une simple réponse de chat. Chaque tour géré s'exécute sur un budget par tour, et les Politiques et limites de l'organisation plafonnent les dépenses par utilisateur, par équipe ou par agent. L'utilisation est mesurée dans l'Analyse d'utilisation au même titre que tout autre agent, attribuée à l'agent externe pour que tu voies ce que coûtent ces exécutions.

Cette comptabilité est une propriété du chemin géré par la passerelle — elle couvre donc les tours gérés de Claude Code, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi et OpenClaw. Les agents gérés par l'environnement et BYO s'exécutent sur des identifiants hors passerelle : leurs tours ne sont pas mesurés dans l'Analyse d'utilisation et les plafonds de dépense de l'organisation ne s'appliquent pas ; le coût et les éventuelles limites de débit relèvent de ton compte de fournisseur.

Agents de code sur le board de tâches

Dans les paramètres, Agent de code est le libellé produit pour les agents dont le chat tourne dans une CLI en bac à sable (Claude Code ou Cursor), ou dont le dispatch de tâches est configuré en JSON avec un runtime (tale-daemon sur ta machine) ou preferDurableStepForTasks (étape durable en bac à sable). Ce libellé ne change pas à lui seul l'exécution sur le board — le dispatch suit ces champs JSON, pas le bac à sable du chat.

Quand tu assignes un agent de code à une tâche du board, le comportement dépend de la configuration :

• Agent (boucle d'outils plateforme, sans CLI bac à sable, sans runtime de tâche) — utilise les outils plateforme et publie les résultats en commentaires de tâche.
• Agent de code + runtime — les tâches s'exécutent sur ta machine (tale-daemon) dans un workspace git.
• Agent de code + preferDurableStepForTasks — les tâches s'exécutent dans un conteneur bac à sable ; le résultat est un fichier de synthèse.
• Agent de code, bac à sable seul (chat external-agent, sans runtime ni flag durable) — le chat tourne en bac à sable ; les tâches du board passent par la boucle plateforme tant que tu n'as pas lié un daemon ou activé les tâches durables dans le JSON de l'agent.

Le sélecteur d'assigné affiche ces indications au choix. Pour la recherche, la rédaction ou des livrables personnels, assigne une personne ou un Agent plateforme plutôt qu'un agent de code orienté dépôt.

Où cela s'inscrit

Un agent externe transforme un fil de discussion en une session en direct avec un outil de code dans un bac à sable — tu le pilotes en langage clair, il travaille dans un espace de travail isolé, et la session persiste pour les suivis jusqu'à ce que tu fermes le fil. Les identifiants sont l'axe qui décide quelle part de tout cela s'exécute sous le contrôle de l'organisation : un agent géré par la passerelle reste sur la passerelle de la plateforme, sous les plafonds et la mesure de l'organisation, tandis qu'un agent géré par l'environnement ou BYO s'exécute sur les clés que tu conserves sous Variables d'environnement et secrets et répond à ton propre compte de fournisseur. Les candidats à la dérive ici sont les noms d'agent et de modèle ; associe cette page à la liste des Fournisseurs en cours plutôt que de mémoriser des chaînes de modèle spécifiques, et à Intégrations pour les intégrations connectées que l'agent peut atteindre — de GitHub pour un véritable flux de pull request à une intégration de recherche ou de données qui amène des faits externes dans le travail. Pour exécuter Claude Code ou Codex sur du matériel que tu contrôles plutôt que dans le bac à sable géré — pour des tâches de board plutôt que du chat —, voir tale-daemon.