Créer des automatisations d'agents efficaces

À mesure que l'IA accélère notre travail, il devient plus difficile de suivre le rythme. Chez Anthropic, des automatisations d'agents simples sont fréquemment utilisées pour aider. Elles s'exécutent souvent selon un calendrier, recueillent du contexte en arrière-plan et nous indiquent de manière proactive ce que nous devons savoir. Mais il est difficile de créer des automatisations d'agents efficaces : elles peuvent perdre l'accès à une source sans que personne ne s'en aperçoive, ou ne pas respecter nos préférences.

En utilisant Claude Managed Agents (bêta), nous avons construit une implémentation de référence qui lit des sources personnalisées (par exemple, Slack et des dépôts GitHub) selon un calendrier, suit ce qui a changé depuis la dernière exécution et publie ce que vous devez savoir (par exemple, sur Slack). Dans cet article, nous passons en revue chaque étape, partageons une implémentation de référence et fournissons une commande à exécuter dans Claude Code qui configure l'agent pour vous.

OBTENIR LE CODE

L'implémentation de référence est ici. Pour une présentation interactive, exécutez la commande ci-dessous dans Claude Code. La claude-api compétence peut aider à configurer l'agent en suivant les conseils de cet article :

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

Pour cette implémentation de référence, vous avez besoin d'une application Slack (créez-la à partir du manifest) et d'un jeton GitHub. Les fichiers fournis (affichés ci-dessous) sont la configuration des ressources de l'API Claude, y compris l'agent, son environnement, les magasins de mémoire, le coffre-fort et le déploiement.

daily-brief/
├── agent.md                        model, tools, instructions
├── deployment.md                   schedule, time zone, budget, input message
├── environment.yaml                network allowlist
├── memory_store_preferences.yaml   user preferences
├── memory_store_state.yaml         the agent's bookmarks, ledger, notes, and run records
├── vault.yaml                      the vault that holds the credentials
├── claude-lock.json                resource IDs, written by ant apply
└── slack/manifest.yaml             one bot app

ant apply, une commande de l'ant CLI, lit ces fichiers, crée les ressources dans votre espace de travail de l'API Claude (où la plateforme les stocke et les exécute) et enregistre les ID dans claude-lock.json.

Nous utiliserons cette commande dans les sections ci-dessous. Une fois configurée, l'automatisation s'exécute selon un calendrier sur l'infrastructure d'Anthropic, de sorte que rien ne doit rester en cours d'exécution sur votre machine.

APERÇU

L'agent que nous allons construire comporte six composants, présentés dans cet ordre :

• Sources - Une liste nommée d'endroits à lire
• Destination - Un seul endroit où l'agent peut écrire
• Agent - Le modèle, les outils et les étapes d'exécution dans agent.md
• Calendrier - Un calendrier cron
• Mémoire - Vos préférences et la mémoire propre de l'agent
• Garde-fous - Un accès en lecture seule partout où l'agent ne fait que lire, et un plafond de dépenses par exécution

SOURCES

L'agent lit deux sources par défaut : les canaux Slack et les pull requests GitHub. Les canaux et les dépôts sont répertoriés dans votre preferences fichier. Le modèle peut être étendu pour utiliser d'autres sources.

Donnez à l'agent ses propres identifiants, avec un périmètre limité

Avec Managed Agents, les identifiants résident dans des coffres-forts (vaults). L'agent peut référencer ces identifiants, mais les valeurs réelles restent dans le coffre, en dehors du sandbox où le code de Claude s'exécute (voir ici et ici):

• Les serveurs MCP (GitHub). L'agent appelle les outils MCP via un proxy qui s'exécute en dehors du sandbox. Le proxy trouve l'identifiant du coffre dont l'URL correspond à celle du serveur.

• Le shell (Slack). L'agent appelle l'API Slack avec curl à l'aide de l'outil bash à l'intérieur du sandbox. Le sandbox ne contient qu'un espace réservé opaque, $SLACK_BOT_TOKEN. Lorsque la requête quitte le sandbox, la plateforme substitue le vrai token pour les hôtes que vous autorisez.

Créez le coffre à l'aide de la ant CLI et du fichier de modèle dans le dépôt :

ant apply vault.yaml

Cela crée le coffre dans votre espace de travail Claude API, où la plateforme le stocke, et enregistre son ID dans claude-lock.json. Ajoutez ensuite chaque identifiant au coffre avec le SDK TypeScript. Voici un exemple montrant l'ajout de l'identifiant Slack :

const vaultId = process.env.VAULT_ID!; // the vault's ID, from claude-lock.json

await client.beta.vaults.credentials.create(vaultId, {
  display_name: "SLACK_BOT_TOKEN",
  auth: {
    type: "environment_variable",
    secret_name: "SLACK_BOT_TOKEN",
    secret_value: process.env.SLACK_BOT_TOKEN!,
    networking: { type: "limited", allowed_hosts: ["slack.com"] },
    injection_location: { header: true },
  },
});

Après avoir créé le coffre et ajouté chaque identifiant, attachez le coffre au déploiement. Copiez l'ID du coffre depuis claude-lock.json dans vault_ids du fichier de déploiement, deployment.md.

Reprenez là où vous vous êtes arrêté

Une erreur courante consiste à demander à l'agent de lire une fenêtre fixe comme "les dernières 24 heures." Une exécution tardive laisse un vide et une exécution précoce répète des éléments. Donnez plutôt à l'agent un signet par source. À la fin de chaque exécution, l'agent écrit l'horodatage de l'élément le plus récent qu'il a lu pour chaque source dans un fichier, bookmarks.json, avec une entrée par source : "slack": "2026-09-14T13:02:11Z".

L'exécution suivante part de ces signets, de sorte que sa fenêtre s'étire ou se réduit pour couvrir tout ce qui s'est passé depuis la dernière exécution. Les signets résident dans le magasin de mémoire appelé state: un dossier de fichiers texte que la plateforme monte dans le bac à sable de chaque exécution sous /mnt/memory/ et conserve entre les exécutions. L'agent le lit et l'écrit avec ses outils de fichiers ordinaires, et les instructions dans agent.md lui indiquent comment.

Ne confondez pas une lecture échouée avec une journée silencieuse

Si un serveur MCP est hors service ou si son jeton a expiré, l'exécution démarre quand même, simplement sans les outils de ce serveur. La session consigne une erreur, mais l'agent ne voit rien de cette source et signale « rien de nouveau. »

Trois règles dans agent.md aident à corriger cela. Lorsqu'une source échoue, l'agent doit : conserver le signet de la source là où il est, rédiger le résumé à partir des autres sources, et terminer le résumé par une ligne indiquant ce qu'il n'a pas pu lire (« pull requests indisponibles lors de cette exécution »), afin que le lecteur en soit informé.

DESTINATION

Notre modèle publie dans un seul canal Slack, avec une publication datée à chaque exécution.

L'agent publie sur Slack en utilisant l'outil bash dans son bac à sable, avec le même jeton de bot qu'il utilise pour lire.

Rien ne doit approuver la publication. L'agent l'envoie avec une commande bash, et l'outil bash intégré s'exécute sans demander d'approbation par défaut. slack.com figure également sur la liste autorisée de l' environnementde l'agent, le bac à sable dans lequel il s'exécute. La publication est une seule requête :

curl -s https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"channel": "C0123456789", "text": "Daily brief, Tue Sep 15 ..."}'

Confirmez que la publication a abouti avant de l'enregistrer

Une fois une publication confirmée, l'agent met à jour son registre des éléments signalés et ses signets. Si ces enregistrements ne correspondent pas à ce qui a réellement été publié, deux problèmes peuvent survenir. Si l'agent enregistre une publication qui n'a jamais abouti, les signets avancent et ces éléments ne sont jamais signalés. S'il publie à nouveau parce qu'il n'est pas certain que la première publication ait abouti, les lecteurs reçoivent le même résumé deux fois.

Trois règles dans agent.md empêchent cela. Premièrement, l'agent recherche le titre du jour dans les messages récents du canal et ne publie pas si l'édition s'y trouve déjà. Deuxièmement, la publication n'est considérée comme envoyée que si Slack renvoie "ok": true et un ts de message. Troisièmement, l'agent ne met à jour le registre et les signets qu'après cette confirmation. Si le résultat n'est pas clair, il marque l'exécution « peut-être publiée » et ne change rien d'autre, afin que rien ne soit perdu.

L'agent conserve un enregistrement d'exécution dans son magasin de mémoire (runs/<date>.md). Il marque l'exécution « posting » avant la publication, puis « posted » avec l'identifiant du message, ou « maybe posted. »

AGENT

Dans Claude Managed Agents, un agent est une configuration versionnée : un modèle, un prompt système et des outils. Chaque exécution suit ses étapes d'exécution puis s'arrête.

Dans notre implémentation de référence, la configuration de l'agent est agent.md:

---
name: Daily brief
model: claude-sonnet-5-5
mcp_servers:
  - type: url
    name: github
    url: https://api.githubcopilot.com/mcp/
tools:
  - type: agent_toolset_20260401
    configs:
      - name: web_search
        enabled: false
      - name: web_fetch
        enabled: false
  - type: mcp_toolset
    mcp_server_name: github
    default_config:
      permission_policy:
        type: always_allow
---

[Eight numbered run steps; the full text is in agent.md in the repo.]

Le frontmatter fournit le nom de l'agent, le modèle, les outils et les serveurs MCP. Le corps contient les instructions de l'agent. Les outils MCP demandent une approbation par défaut et personne n'est là pour l'accorder, donc l'ensemble d'outils GitHub est configuré sur always_allow et le token GitHub est read-only.

Gardez le brief court

agent.md oriente Claude vers la concision :

4. Decide. An item earns a line when the reader would act on it today, or it changes a decision they are about to make. When unsure, leave it out. Most days that is a few items, sometimes none. A count ("12 open reviews") is not an item; link the ones that are blocked. An item already in the ledger and still open is carried as one marked line ("still waiting, day 3"), not re-reported; a closed item is dropped without comment. Do not bring back a topic the preferences file has retired.

Revérifiez tout ce qui reste ouvert juste avant de publier

Les éléments peuvent changer entre le moment où l'agent lit les sources et le moment où il publie. Juste avant de publier, agent.md invite l'agent à revérifier le statut en direct de chaque article :

5. Verify. The world moved while you read. For every item you will report, re-check its live source just before posting: resolved since you read it, drop it; still open but changed, fix the line; cannot confirm, drop it and list it in the run record's cuts. One stale "still waiting on you" costs more trust than ten missing items, so never hedge an item's status: assert it or drop it. Every link is copied from the source's own link field (a pull request's html_url, a Slack permalink), never assembled by hand.

PROGRAMME

Avec Claude Managed Agents, l'agent n'est qu'un fichier de configuration ; un déploiement l'exécute. Le déploiement nomme l'agent, l'environnement et le premier message de chaque exécution. Il contient également le calendrier, le coffre, les magasins de mémoire et le budget. Chaque fois que le calendrier se déclenche, la plateforme démarre un nouvel agent session.

Dans notre modèle, le déploiement est capturé dans deployment.md, avec le premier message comme corps :

---
name: Daily brief
agent: ./agent.md
environment_id: ./environment.yaml
schedule:
  type: cron
  expression: "32 7 * * 1-5"
  timezone: America/New_York
vault_ids: [vlt_...]   # the vault you create under Sources
resources:
  - path: ./memory_store_preferences.yaml
    access: read_only
    instructions: The reader's preferences. Re-read them every run. Never write here.
  - path: ./memory_store_state.yaml
    access: read_write
    instructions: Your state. Bookmarks, ledger, notes, proposals, and run records.

---

Write today's brief.
The reader's time zone is America/New_York. Work out every date in that zone.

Follow your run steps in order. Today's edition is titled "Daily brief, <weekday> <month> <day>".

Cela crée le déploiement avec l'agent, l'environnement et les magasins de mémoire qu'il nomme par chemin.

ant apply deployment.md

Pour le tester sans attendre la planification, lancez une exécution à la main avec ant beta:deployments run --deployment-id <id>, en utilisant l'ID de claude-lock.json.

Calculer les dates dans votre fuseau horaire

Un bug courant est que l'agent appelle ce matin « hier », car il calcule les dates dans le fuseau horaire du serveur. Dans deployment.md, le champ timezone définit le moment où l'exécution se déclenche et la seconde ligne du corps indique à l'agent quel fuseau utiliser pour les dates.

MÉMOIRE

Chaque exécution démarre dans un bac à sable neuf, sans mémoire de la précédente. Sans mémoire, le retour d'information ne s'accumule pas. Cependant, une mémoire périmée peut troubler l'agent : il signale un élément comme toujours en attente alors qu'il a été résolu, ou en écarte un qui est toujours ouvert parce qu'il a été « déjà signalé ».

Notre modèle conserve deux magasins de mémoire, les dossiers montés sous /mnt/memory/ (voir Sources) :

• preferences (le vôtre, en lecture seule pour l'agent) : quels canaux et dépôts lire, quoi omettre, la limite de longueur, la destination et quand s'arrêter.

• state (celui de l'agent, en lecture-écriture) : les signets, un registre de ce qu'il a signalé, un enregistrement par exécution, les modifications qu'il propose à vos préférences, et des notes sur le comportement de chaque source (« ne renvoie que les 50 éléments les plus récents »).

ant apply deployment.md crée le magasin preferences, mais pas le fichier qu'il contient. Avant la première exécution, écrivez-y votre preferences.md avec le scripts/seed-preferences.sh.

Relire vos préférences au début de chaque exécution

Un problème courant survient lorsqu'une copie des préférences est figée dans le prompt, ce qui continue d'appliquer des règles que vous avez déjà modifiées. Faites en sorte que l'agent lise le fichier à chaque exécution. S'il ne peut pas lire le fichier, il doit s'arrêter et le dire au lieu de fonctionner avec les valeurs par défaut.

Tenir un registre de ce que vous avez déjà signalé, et signaler le changement

L'agent tient un registre, ledger.md, de chaque élément qu'il a signalé, afin que le brief ne se répète pas. Chaque ligne enregistre quand l'élément a été signalé, d'où il provient, un identifiant qui ne change pas (l'horodatage d'un message Slack ou le numéro d'une pull request), et son dernier statut connu :

2026-09-09 slack:C0123456789 1788963600.000100 refund thread: customer waiting on a decision
2026-09-11 github 481 review blocked, day 2 (still waiting)
2026-09-11 slack:C0234567891 1789117333.000300 enterprise escalation: owner named, in progress

GARDE-FOUS

Comme notre automatisation fonctionne « en arrière-plan » selon un calendrier, nous fixons des limites à ce que l'agent peut faire et à ce qu'il peut dépenser.

Limites sur ce qu'il peut faire

L'agent lit des messages et des tickets écrits par d'autres personnes, et ce texte peut être interprété comme des instructions. Limitez ce que l'agent pourrait faire s'il les suivait. Dans notre exemple, le jeton GitHub et le magasin preferences sont en lecture seule, et l'environnement n'atteint que les hôtes de sa liste d'autorisation. Une instruction plantée peut néanmoins modifier ce que dit le brief, y compris par les notes que l'agent conserve entre les exécutions. Il ne peut pas écrire sur GitHub ni modifier vos règles.

Slack est l'exception : le même jeton publie, donc n'invitez le bot que là où il doit lire ou publier.

Fixer le plafond de dépenses à partir d'exécutions réelles

Un plafond de dépenses vous protège des coûts incontrôlables. Commencez à trois à cinq fois le coût d'une exécution normale, puis resserrez-le à mesure que vous voyez des chiffres réels. Une exécution qui atteint son plafond se met en pause au lieu d'échouer, si bien qu'un plafond trop bas ressemble à un brief devenu silencieux. Le plafond est le budget dans deployment.md. Chaque exécution reçoit le montant complet, et une exécution qui l'atteint se met en pause avec une budget_reached raison d'arrêt :

budget:
  type: limit
  max_list_cost:
    amount: "500" # a string, in cents: "500" is $5.00
    currency: USD

PRISE EN MAIN

Notre implémentation de référence se résume à six règles :

• Lisez chaque source à partir d'un signet, et non d'une fenêtre temporelle fixe.
• Signalez une lecture échouée comme illisible, jamais comme une journée calme.
• Revérifiez chaque élément juste avant la publication.
• Comptez une publication comme envoyée uniquement lorsque Slack la confirme, puis mettez à jour les signets et le registre.
• Relisez vos préférences à chaque exécution, à partir d'un magasin que l'agent ne peut pas modifier.
• Donnez à l'agent un accès en lecture seule partout où il ne fait que lire, et plafonnez ce que chaque exécution peut dépenser.

Claude Code peut vous guider pas à pas dans les conseils fournis dans cet article. Commencez par mettre à jour :

claude update

Ensuite, utilisez la compétence claude-api :

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

La compétence claude-api lit ce billet, propose une configuration, écrit les fichiers dans un dossier agents/ de votre projet et crée les ressources avec ant apply. Considérez cela comme un point de départ et personnalisez l'agent selon vos sources, votre destination ou vos préférences de mémoire.