La boucle d'agent, hébergée pour vous

Claude Managed Agents est une suite d'APIs pour construire et déployer des agents à grande échelle. Vous définissez des agents avec des outils, des personas et des capacités spécifiques. Vous configurez des environnements sandbox avec les bons packages et contrôles réseau. Ensuite, vous lancez des sessions depuis votre propre application, et Claude fait le travail à l'intérieur d'un conteneur isolé avec accès complet au système de fichiers, exécution bash et recherche web.

La boucle d'agent, hébergée pour vous

Sous le capot, c'est une boucle d'agent : Claude raisonne, appelle un outil, lit le résultat, et répète jusqu'à ce que le travail soit terminé. Si vous avez construit des agents auparavant, vous avez probablement écrit ce genre de boucle vous-même. Managed Agents prend cette même boucle et l'héberge sur l'infrastructure d'Anthropic, donc vous n'avez pas à la faire fonctionner.

Vous trouverez Managed Agents dans sa propre section de la Claude Console.

La meilleure façon de comprendre ce que cela déverrouille est de parcourir quelques exemples.

Exemple 1 : Un tableau Kanban qui fait le travail

Imaginez un tableau Kanban assis sur des agents gérés. Vous faites glisser un ticket dans la colonne « en cours », et cela déclenche automatiquement une session. Disons que le ticket dit « optimiser les performances du site web ». Voici ce qui se passe :

Votre back end crée une session.
La session pointe vers un environnement que vous avez configuré avec Lighthouse et Puppeteer pré-installés.
Votre repo GitHub est monté dans le conteneur.

Maintenant Claude a la base de code, les outils, et un rubrique qui définit ce que « fait » signifie :

Score Lighthouse supérieur à 90
Aucune ressource bloquant le rendu
Toutes les images chargées en différé

Claude exécute l'audit, puis commence à compresser les images, à intégrer le CSS et à différer les scripts. Chaque appel d'outil est diffusé en temps réel vers le tableau via le flux d'événements, donc vous pouvez regarder le travail au fur et à mesure qu'il se fait.

Ensuite, la rubrique s'active. Un évaluateur séparé, fonctionnant dans sa propre fenêtre de contexte, évalue la sortie par rapport à vos critères. Claude lit ce retour, revient, corrige ce qu'il a manqué, et remet. Dans la démo, cette boucle porte le score Lighthouse à 96.

Une dernière chose : vous pouvez faire glisser un deuxième ticket pendant que le premier s'exécute toujours. Deux sessions, deux conteneurs, deux tâches séparées s'exécutant en parallèle.

Un tableau de développement Kanban avec deux tickets dans la colonne En cours, chacun exécutant sa propre session d'agent et diffusant des événements d'appel d'outil

Exemple 2 : Un agent de recherche récurrent avec mémoire

Voici une forme différente d'agent : celui dont le travail est de suivre les prix et de planifier les changements dans tous les outils SaaS que votre entreprise paie, avec un rapport prêt avant la réunion d'équipe.

L'application Pricing Research avec un bouton Run Weekly Report, un flux d'activité d'agent vide, un panneau de mémoire et une liste de livrables avec un rapport Excel et un résumé exécutif

À chaque exécution, l'agent :

Recherche sur le web les pages de tarification actuelles, vérifie les changements de niveaux de plan et signale les nouvelles fonctionnalités qui pourraient affecter vos contrats
Exécute une analyse de coûts en Python à l'intérieur du sandbox
Utilise une compétence de feuille de calcul Excel et rédige un résumé exécutif
Publie un lien sur Slack et crée une tâche d'examen dans Asana, tous deux via des serveurs MCP

L'agent lit également et écrit dans un magasin de mémoire. Avant de commencer, il vérifie ce qu'il a trouvé la semaine dernière. Après avoir terminé, il stocke ce qui a changé. Donc le rapport de lundi prochain peut dire « les coûts de calcul sont 15 % plus bas depuis la semaine dernière » au lieu de lister les mêmes données de tarification statiques à chaque fois.

Le panneau de mémoire listant les découvertes de la semaine dernière, y compris les changements de tarification des fournisseurs et une estimation des dépenses mensuelles totales que l'agent a stockée pour sa prochaine exécution

Exemple 3 : Réponse aux incidents avec plusieurs agents

Imaginez maintenant qu'une alerte se déclenche à partir de votre pile de surveillance. Un outil personnalisé sur votre back end reçoit la charge utile d'alerte et l'envoie dans une nouvelle session en tant que résultat d'outil. Cette session utilise la coordination multi-agent :

Un agent coordinateur reçoit l'alerte et délègue à trois spécialistes.
Chaque spécialiste s'exécute dans sa propre fenêtre de contexte sur le même système de fichiers partagé.
Les spécialistes font rapport, et le coordinateur synthétise leurs conclusions en un seul résumé d'incident.

Un tableau de bord de réponse aux incidents pour une alerte de pic de latence API, avec des panneaux Diagnostics, Log Analysis et Communications specialist en attente tandis qu'un panneau Past Incidents recherche des motifs en mémoire

Avant que le résumé ne soit envoyé à Slack, la politique de permissions s'active. Vous voyez le brouillon à l'écran, l'approuvez, et le message est envoyé. Les actions sensibles attendent un humain.

La mémoire lie tout cela ensemble. Le coordinateur vérifie les incidents passés dans le magasin de mémoire et signale un motif : « cela ressemble au problème de résolution DNS d'il y a deux semaines qui a été causé par un TTL mal configuré. » La prochaine fois qu'une alerte similaire se déclenche, l'agent commence avec ce contexte au lieu de diagnostiquer à partir de zéro.

Les éléments constitutifs

Dans tous ces exemples, les agents gérés donnent aux développeurs les outils pour fournir une expérience d'agent entièrement gérée et avec état construite sur :

Agents — définitions avec des outils, des personas et des capacités spécifiques
Sessions — des exécutions individuelles que vous lancez depuis votre propre application
Environnements — des sandboxes avec les bons packages et contrôles réseau
Outils — y compris des outils personnalisés sur votre back end
MCP — connexions à des services comme Slack et Asana
Mémoire — un magasin que l'agent lit avant de commencer et écrit quand il a terminé
Résultats — des rubriques et des évaluateurs qui définissent et vérifient ce que « fait » signifie
Coordination multi-agent — coordinateurs déléguant à des spécialistes

Récapitulatif

Claude Managed Agents est une suite d'APIs pour construire et déployer des agents à grande échelle, hébergée sur l'infrastructure d'Anthropic.
Elle exécute la boucle d'agent familière — raisonner, appeler un outil, lire le résultat, répéter — à l'intérieur d'un conteneur isolé avec accès au système de fichiers, exécution bash et recherche web.
Les sessions s'exécutent dans des environnements que vous configurez, fonctionnent en parallèle, et diffusent les appels d'outil vers votre application en temps réel.
Les rubriques et les évaluateurs séparés vous permettent de définir les critères de succès ; Claude itère jusqu'à ce qu'il les atteigne.
La mémoire, les serveurs MCP, les outils personnalisés, les politiques de permissions et la coordination multi-agent complètent l'expérience d'agent avec état.
Vous définissez ce que « fait » signifie. Claude travaille jusqu'à ce qu'il y arrive.