Comment un représentant en développement commercial d’Anthropic au Japon organise sa journée avec les Agents gérés de Claude
Comment un représentant en développement commercial traite ses demandes entrantes et rédige des e-mails clients bilingues avec les Agents gérés de Claude et Claude Tag.
En tant que chargé de développement commercial au sein de l'équipe japonaise d'Anthropic, ma mission consiste à montrer aux entreprises japonaises comment Claude peut simplifier et automatiser leurs flux de travail, mais jusqu'au début de cette année, la plupart de mes propres processus étaient encore manuels. Chaque matin, je passais quelques heures à répartir et qualifier des prospects, puis à rédiger des e-mails en japonais ou en anglais. Le reste du temps, je mettais à jour notre CRM, souvent avec un retard d’une journée ou plus. Désormais, mes agents effectuent l’essentiel de ce travail préparatoire avant même que je ne commence ma journée et je vérifie leur travail.
Le premier flux de travail exécuté par Claude que j'ai créé était assez rudimentaire, mais il faisait l'affaire. Je confiais à Claude une tâche à la fois, je corrigeais les erreurs et je sauvegardais ces corrections. Au fil du temps, ce système s'est transformé en une poignée d'agents, chacun chargé d’une tâche de routine différente.
La nouvelle s'est vite répandue et mes collègues ont commencé à me demander mes requêtes et mes skills pour créer les leurs. Tout ce que je pouvais leur envoyer, c'était un fichier zip contenant mes skills et quelques fichiers Markdown issus de la base de connaissances. Ils devaient ensuite importer ces fichiers dans Claude, puis répondre à une série de questions de configuration avant que tout ne fonctionne. Il était également de plus en plus difficile de suivre ma propre configuration. Chaque agent se composait d'une skill, d'une tâche planifiée et d'un dossier partagé, et je les modifiais en donnant mes instructions à Claude dans la conversation que j’avais ouverte à ce moment-là, si bien qu’une même skill pouvait être modifiée à partir de multiples conversations.
Je voulais définir chaque agent une seule fois, à un seul endroit, et pouvoir visualiser toutes les modifications que j'y avais apportées. J'ai donc décidé d'essayer les Agents gérés de Claude (opens in new tab) (bêta), notre infrastructure d’agents gérés sur Claude Platform.
Au début, j'hésitais à les essayer. La documentation parle de plannings, d’outils et de coffres-forts sécurisés pour les identifiants, et comme je suis commercial, j’ai supposé que les Agents gérés étaient destinés aux développeurs capables de créer et de maintenir l’infrastructure nécessaire. J’ai quand même essayé parce que j’avais déjà mes propres agents, il me suffisait de les migrer.
Il s'est avéré que je n'avais pas besoin d'être développeur. J'ai décrit le rôle de chaque agent en langage simple, Claude a généré quelques courts scripts de configuration, et je les ai exécutés depuis le terminal de mon ordinateur portable. (Si vous partez de zéro, la Console propose également un guide de démarrage rapide avec des modèles d'agents prêts à l'emploi.) Depuis, je n'ai plus aucune infrastructure à gérer.
Dans cet article, je vais expliquer comment j'ai conçu et prototypé l’équipe d'agents, pourquoi je l'ai migrée vers les Agents gérés, comment Claude Tag prend en charge tout ce qui sort de la routine, comment tout cela a transformé mon organisation hebdomadaire et ce que je dirais aux commerciaux qui souhaitent créer leurs propres agents pour automatiser les flux de travail manuels et répétitifs.
Concevoir mon équipe d'agents
J'ai réparti mon flux de travail entre plusieurs agents et attribué à chaque agent une tâche précise. Chaque agent étant responsable d’une seule tâche, il reste facile à comprendre et à surveiller, surtout lorsque quelque chose ne va pas. J'ai donné à chaque agent un nom japonais, car ils travaillent principalement en japonais. Ensemble, on les appelle les Nakama, qu’on pourrait traduire par « l'équipage » ou, plus littéralement, les compagnons avec lesquels on travaille :
- Furiwake (« tri ») se lance en premier : il lit la file d’attente quotidienne des demandes entrantes et attribue chaque lead au commercial approprié de l’équipe, en répartissant les leads en fonction de leur nombre et de leur priorité, et en vérifiant qui est présent ce jour-là, pour que chaque lead soit assigné à un responsable avant même que nous commencions notre journée. À la fin de chaque exécution, l’outil publie un rapport sur un canal Slack dédié (tous les leads reçus et leur attribution respective) pour que je puisse suivre le transfert.
- Sabaki (« traitement ») effectue un premier traitement des leads qui me sont attribués : il qualifie chaque lead, le classe selon des critères prédéfinis, passe à l’étape suivante définie pour cette catégorie (rédiger une réponse l’orientant vers les ressources en libre-service, créer un premier e-mail personnalisé), met à jour le dossier du lead dans Salesforce et rédige l’e-mail de premier contact. Il puise le contenu du brouillon dans la base de connaissances partagée des Nakama, un espace de mémoire (opens in new tab) que chaque agent consulte et enrichit (plus d’informations ci-dessous).
- Une fois par heure, Henji (« réponse ») recherche dans ma boîte de réception les e-mails de clients nécessitant une réponse et prépare un brouillon en japonais ou en anglais, selon le fil de discussion, en s'appuyant sur la même base de connaissances que Sabaki. Je peux relire ce brouillon, le modifier et l’envoyer.
- Shoudan (« opportunité ») lit les interactions récentes avec les clients et met à jour les informations dans Salesforce, pour que les dossiers d’opportunité restent à jour, sans nécessiter de saisie manuelle.
- Nokori (« ce qui reste ») s'exécute en fin de journée : il analyse mon agenda, lit les transcriptions de réunion jointes, résume chaque réunion et rédige les e-mails de suivi, toujours à partir de la même base de connaissances.
Chaque agent s'exécute selon un planning. Un sixième agent, le coordinateur des Nakama, est le responsable des opérations de l’équipe. Entre les exécutions, il met à jour les instructions des agents et la base de connaissances partagée. Lorsque je souhaite modifier le fonctionnement d’un agent, j’écris ce que je veux en termes simples dans le canal Slack des Nakama. Je suis le seul à pouvoir publier des demandes de modification des instructions et des requêtes système des agents. Le coordinateur vérifie ce canal environ toutes les 15 minutes, prend en charge la demande et effectue la mise à jour.

Créer des prototypes de mon équipe d’agents avec Claude
Vous n'avez pas besoin d'Agents gérés pour vous lancer. J'ai commencé par créer un prototype de toute mon équipe d’agents avec Claude, à l'aide des éléments suivants :
- Une skill par agent : les instructions correspondant à une tâche précise.
- Une tâche planifiée pour chaque skill, pour que je n'aie pas à l'exécuter manuellement.
- Un dossier partagé sur mon ordinateur portable, servant de base de connaissances dans laquelle chaque skill consigne ce qu’elle a appris : la différence entre ce qu’elle a rédigé et ce que j’ai envoyé, ainsi que toute nouvelle information trouvée au cours de ses recherches.
Avec les Agents gérés, la skill est devenue la requête système de l'agent, la tâche planifiée est devenue un planning intégré au déploiement de l'agent (opens in new tab) et le dossier partagé est devenu un espace de mémoire. Je demande toujours des modifications en langage naturel, mais désormais je fais tout dans un seul canal Slack. Chaque modification apportée aux instructions d’un agent est enregistrée sous forme de nouvelle version, pour que chaque agent conserve un historique numéroté des instructions qu’il a reçues. Je vous conseille de commencer par Claude et d’effectuer le transfert vers vos Agents gérés lorsque leur nombre devient difficile à gérer.

Gérer l’équipe d’agents avec les Agents gérés de Claude
Les trois éléments des Agents gérés qui ont le plus compté pour mon flux de travail :
Les agents peuvent s'exécuter en arrière-plan
Les agents fonctionnent selon leur planning défini, que mon ordinateur portable soit ouvert ou non, même lorsqu'il est hors ligne. Le planning fait partie du déploiement de chaque agent. J’aurais également pu planifier des skills dans Claude, mais chaque planning correspondait à une tâche configurée dans mon application Claude. Avec les Agents gérés, je définis la cadence et le fuseau horaire dans la console, à côté des instructions et des outils de l’agent déployé. Je n’ai pas besoin de gérer de tâches cron séparément. Si une exécution se déroule mal, je peux l’ouvrir dans la console et voir chaque étape suivie par l’agent. Et pendant que je teste une modification d'un agent, les exécutions programmées continuent d'utiliser la version déployée, de sorte qu'une modification inachevée n’est pas reprise dans l'exécution du lendemain.
Les agents Nakama partagent une mémoire commune et apprennent de mes corrections
Tous les agents consultent et alimentent la même mémoire partagée (opens in new tab), si bien que chaque agent peut tirer parti de ce que les autres ont appris. Les agents comparent les brouillons qu'ils ont rédigés avec les e-mails que j'ai envoyés, et ils enregistrent chaque différence sous forme de note indiquant comment je formulerais les choses. Ils conservent également toutes les nouvelles informations qu'ils découvrent lors de leurs recherches, dans nos documents internes et sur nos sites officiels. Lorsque je corrige une formulation dans les brouillons de Henji, Sabaki et Nokori ne commettent plus la même erreur.
Les identifiants sont conservés dans un coffre-fort géré avec des autorisations d’accès limitées à des usages précis.
Mes agents ont accès à mes e-mails et à nos dossiers Salesforce, mais comme il s'agit de conversations avec des clients et de dossiers de l'entreprise, je voulais conserver le contrôle de l’accès. Les identifiants sont stockés dans des coffres-forts gérés (opens in new tab), qui protègent les identifiants utilisés par les agents pour se connecter à des services externes, tels que les jetons d’accès et de renouvellement OAuth, les clés API et les jetons d’accès personnels. Chaque agent déployé utilise uniquement les coffres nécessaires à sa mission, sans jamais avoir accès aux identifiants eux-mêmes. Je peux par ailleurs révoquer les autorisations en une seule opération.
Confier les étapes suivantes à Claude Tag
Pour la plupart des éléments produits par le Nakama, je n’ai plus qu’à lire un brouillon dans ma boîte de réception avant de l'envoyer, ou vérifier un enregistrement Salesforce mis à jour. Mais certains éléments nécessitent une étape de suivi, par exemple pour déterminer les modalités de passage à une offre supérieure ou la procédure d'achat à suivre, ou encore pour transmettre un problème à une autre équipe.
Dans ces cas-là, les agents ne s'arrêtent pas pour m'attendre. Ils transmettent l'élément à Claude Tag (opens in new tab) (en version bêta). Claude Tag, c’est Claude configuré comme membre de notre espace de travail Slack : tout membre d’un canal que Claude a rejoint, qu’il s’agisse d’une personne ou de l’un de mes agents, peut mentionner @Claude dans une requête : Claude la prend en charge et la traite directement dans le fil de discussion. Une fois Claude Tag configuré dans votre espace de travail, il n’y a plus rien de nouveau à apprendre. Il vous suffit de mentionner Claude comme vous le feriez avec un collègue.
Dans ma configuration, cela fonctionne comme suit. Un agent publie l’action à mener sur le canal Slack du Nakama et mentionne Claude. Claude lit le fil de discussion, vérifie nos règles et les conditions applicables, présente les options et rédige les éléments nécessaires. Claude me mentionne lorsqu'une étape nécessite ma relecture ou ma validation. Lorsqu'un client ou une autre équipe doit répondre en premier, Claude programme un rappel pour effectuer une nouvelle vérification à une date précise. Dans le fil de discussion ci-dessous, Claude a programmé un rappel pour mardi afin de vérifier si le client a répondu et si l’équipe chargée de la validation des offres commerciales a traité le ticket. À l’échéance du rappel, Claude vérifie si les deux réponses sont arrivées et publie un point sur la situation dans le même fil. Si quelqu’un doit être relancé, Claude rédige le message et me mentionne pour que je l'envoie.

Chaque matin, Claude publie également un résumé des mises à jour relatives aux produits et aux tarifs. Le coordinateur des Nakama récupère ce résumé et intègre les modifications nécessaires dans la base de connaissances partagée.
Qu’est-ce qui a changé dans ma semaine
Maintenant que Claude prépare les réponses aux demandes entrantes et tient à jour les enregistrements CRM sans intervention manuelle de ma part (ou presque), mon rôle consiste à examiner tout ce qui nécessite un jugement humain. Un ensemble de règles écrites définit le périmètre d’intervention de chaque agent, et les éléments tels que les questions de tarification, les comptes sensibles ou les demandes ambiguës me sont transmis. Chaque brouillon d’e-mail envoyé par Henji, Sabaki ou Nokori comporte en en-tête un court résumé de la situation. Je n’ai donc pas à suivre l’ensemble du fil de discussion pour comprendre le contexte : je lis le résumé, je vérifie le contenu, j’apporte les modifications nécessaires et j’envoie le message.

D’après le journal hebdomadaire des tâches réalisées par les Nakama et selon mon estimation du temps que chacune m’aurait demandé manuellement, l’équipe me fait gagner environ 60 heures de travail. Je consacre le temps ainsi libéré à des tâches que les agents ne peuvent (encore) pas effectuer efficacement : conversations avec les clients, stratégie de prospection commerciale, projets transversaux et aide aux membres de l’équipe pour créer leurs propres équipes d’agents.
Concevoir des agents plus efficaces
Les agents planifiés s'exécutant tous les jours, que je les surveille ou non, les inefficacités peuvent vite se multiplier, entraînant des coûts supplémentaires et des problèmes de fiabilité. Parmi les erreurs les plus courantes : compléter des instructions existantes plutôt que de les mettre à jour, fournir aux agents plus de contexte qu'il n'en faut pour leurs tâches et exécuter chaque tâche sur le modèle le plus puissant avec le niveau d'effort le plus élevé.
Si les agents restent efficaces, c'est surtout grâce à la conception de l’équipe : chaque agent n'a qu'une seule mission, de sorte que ses instructions restent centrées sur cette mission ; chaque agent opérationnel s'exécute selon un planning, de sorte qu'il se lance, exécute sa tâche, puis s'arrête ; et les agents partagent une mémoire, de sorte qu'une correction effectuée une seule fois peut être réutilisée par tous les agents.
L'autre facteur important est le modèle sur lequel s'exécute chaque agent. Une fois le rôle d'un agent bien défini, il n'a pas forcément besoin de notre modèle le plus performant. Furiwake et Shoudan suivent des règles écrites, ce qui permet de les exécuter sur Sonnet, notre modèle plus léger. Sabaki, Nokori et le coordinateur utilisent Opus, notre modèle plus puissant, car leur travail nécessite plus de discernement. Le coordinateur en a le plus besoin, car il modifie les instructions des autres agents et une seule modification incorrecte se répercuterait sur tous les agents. Henji a autant besoin de discernement que Sabaki, car les e-mails de chaque client sont différents, mais il s’exécute également plus souvent que tout autre agent, tout au long de la journée de travail. L’utiliser systématiquement sur Opus serait l’option la plus coûteuse. J’utilise donc la stratégie du conseiller (opens in new tab) proposée dans les Agents gérés : Henji s’appuie sur Sonnet. Lorsqu’il doit prendre une décision qu’il ne peut pas prendre seul, il demande conseil à Opus. Le conseiller examine le travail déjà effectué par Henji et lui renvoie un plan, une correction ou un signal d'arrêt, puis Henji termine le brouillon pour que je le relise. Je définis également le niveau d’effort de chaque agent (le temps de réflexion du modèle avant de répondre) séparément de son modèle, et je ne l’augmente que pour les tâches qui nécessitent un raisonnement complexe, comme c’est le cas pour les réponses de Henji.

Leçons tirées
Trois conseils que je donnerais à tous ceux qui souhaitent créer leur propre équipe d'agents.
- Vous n'avez pas besoin de rédiger une requête détaillée à chaque fois. Décrivez la tâche une seule fois, laissez Claude produire un premier jet, corrigez-le et laissez Claude mémoriser vos corrections
- La base de connaissances compte davantage que la requête elle-même. Chaque correction et chaque interaction passée sont enregistrées dans un espace où tous les agents peuvent lire et écrire. Claude y puise donc le contexte plutôt que dans une requête plus longue. Il a fallu quelques centaines de cycles de rédaction, de correction et d’enregistrement, à moindre coût, pour que les ébauches reflètent mon style.
- Donnez davantage d'autonomie à Claude dès le départ. Au début, je continuais à effectuer les tâches qui, selon moi, nécessitaient mon intervention : mettre à jour la base de connaissances ou modifier manuellement les instructions de chaque agent. Ces deux tâches ont été parfaitement prises en charge dès que j'ai accepté de les déléguer. Désormais, les agents écrivent eux-mêmes ce qu'ils apprennent dans la base de connaissances, et le coordinateur met à jour les instructions des autres agents lorsque je le demande en langage naturel. J’avais été trop prudent quant aux tâches que je pouvais confier aux agents.