Blog · Guide · 28 octobre 2026

Exécuter un agent planifié avec AEGIS : planifications, exécutions et ce que vous voyez quand l'une échoue

Aussi en: English, Español, Português, 日本語, Deutsch, 한국어, 简体中文, Italiano, हिन्दी · Tous les guides en français

Transparence : 100monkeys.ai développe AEGIS, lisez donc ce guide comme le récit de son fabricant. Il a été rédigé par l'un de nos agents d'IA à partir de la documentation publique d'AEGIS, principalement la page Schedules et la référence Schedule Tools, puis relu par l'entreprise ; cette édition française est une traduction du guide original en anglais. Chaque champ, route et message ci-dessous est cité de ces pages, en anglais avec la traduction à côté. Nous n'avons pas exécuté ces appels pour ce guide, et là où la documentation laisse une étape ouverte, nous le disons.

AEGIS by 100monkeys.ai, in beta, est un orchestrateur auto-hébergé qui exécute des agents autonomes dans des environnements isolés et soumis à des politiques. Ce guide place l'un de vos agents sur une minuterie, relit ce qu'a fait chaque déclenchement et montre les quatre issues possibles, pour qu'une exécution qui n'a pas eu lieu soit aussi visible qu'une exécution qui a eu lieu.

Ce qu'est une planification

La documentation la définit en une phrase : "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence." (Une planification lance l'un de vos agents ou workflows en votre nom, soit une fois à l'heure choisie, soit à répétition selon une récurrence.) Trois conséquences en découlent, et chacune façonne les étapes ci-dessous.

• Une planification est votre propre objet, "never a field of the agent or workflow it runs" (jamais un champ de l'agent ou du workflow qu'elle exécute).
• Elle s'exécute en tant que personne. "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one." (Une planification s'exécute toujours en tant que personne. Un compte de service, ou un opérateur qui n'agit pour personne, ne peut ni en créer, ni en modifier, ni en suspendre, ni en reprendre, ni en exécuter, ni en supprimer.)
• Chaque déclenchement est une exécution ordinaire. "At each fire the orchestrator starts the run exactly as aegis.task.execute or aegis.workflow.run would for you, with the schedule's intent, input and connections." (À chaque déclenchement, l'orchestrateur lance l'exécution exactement comme le feraient pour vous aegis.task.execute ou aegis.workflow.run, avec l'intention, l'entrée et les connexions de la planification.)

Étape 1. Choisir l'agent et le moment

Prenez un agent que vous avez déjà lancé une fois à la main avec aegis task execute <AGENT>, pour savoir à quoi ressemble une bonne exécution.

Choisissez ensuite l'un des deux modes. Vous en donnez exactement un.

• Une fois : at, une heure RFC 3339 "at least one minute from now and at most a year ahead" (au moins une minute à partir de maintenant et au plus un an à l'avance).
• Récurrent : recurrence avec cron, timezone et jitter_seconds. Le cron a cinq champs (minute, heure, jour du mois, mois, jour de la semaine), "no seconds field and no @daily-style shorthand" (pas de champ des secondes et pas de raccourci du type @daily). Le fuseau horaire est un nom IANA, UTC par défaut. Le jitter retarde chaque exécution d'une durée aléatoire jusqu'à ce nombre de secondes, 3600 au plus.

Deux limites à prévoir : "A schedule runs at most once every 5 minutes" (une planification s'exécute au plus une fois toutes les 5 minutes), et vous pouvez détenir au plus 25 planifications non supprimées.

Étape 2. Choisir ce que l'exécution peut atteindre

Une exécution planifiée n'atteint que les connexions nommées par son profile ou ses contexts, et "a schedule with neither reaches none of your connections." (une planification sans l'un ni l'autre n'atteint aucune de vos connexions.) Une planification porte l'un ou l'autre, jamais les deux. Si votre agent lit du courrier ou un dépôt, nommez le profil dès maintenant ; sinon le déclenchement sera refusé faute de connexion, et le refus le dira.

Étape 3. Créer la planification

La CLI Reference ne contient aucune commande shell aegis schedule. Vous créez une planification avec la route REST POST /v1/schedules (scope schedule:write), avec l'outil MCP aegis.schedule.create, ou depuis la page Schedules de Zaru. L'outil prend ces arguments, tels que la référence les liste :

aegis.schedule.create {
  "name": "Morning inbox triage",
  "target_kind": "workflow",
  "target": "email-inbox-triage",
  "intent": "Sort the new mail",
  "input": { "mailbox": "ann@example.com" },
  "recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}

Cet exemple est la planification de la documentation elle-même. Passez target_kind à agent et target au nom de votre agent. La réponse est {"schedule": {...}} avec son state, son next_run_at et son last_run. Relisez next_run_at avant de partir.

Étape 4. La déclencher une fois, maintenant

N'attendez pas la première heure planifiée pour savoir si cela marche. Le propriétaire peut lancer une exécution immédiatement avec POST /v1/schedules/{id}/run ou aegis.schedule.run_now. Elle s'exécute "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments" (exactement comme un déclenchement la lance : en tant que propriétaire, avec la cible, l'entrée, les connexions ou le profil et les pièces jointes de la planification), et "nothing else changes" (rien d'autre ne change) : la planification garde son état et son calendrier.

Étape 5. Lire les exécutions

aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }

La route est GET /v1/schedules/{id}/runs?limit=. Les exécutions arrivent de la plus récente à la plus ancienne, chacune avec scheduled_time (null pour une exécution lancée maintenant), fired_at, outcome, detail et execution (son id, son kind et son status). Portez l'id d'exécution dans la CLI pour lire l'exécution elle-même : aegis task logs <EXECUTION_ID>, avec --errors-only si vous ne voulez que les échecs.

Étape 6. Connaître les quatre issues

Chaque déclenchement est enregistré une fois par heure planifiée ; un déclenchement que Temporal répète "answers the first fire's record instead of starting a second run" (renvoie l'enregistrement du premier déclenchement au lieu de lancer une seconde exécution). Chaque enregistrement a une seule issue :

• started: l'exécution a démarré, et le déclenchement enregistre son id d'exécution.
• skipped_overlap: "The run the previous fire started is still running, so this fire starts nothing." (L'exécution lancée par le déclenchement précédent tourne encore, donc ce déclenchement ne lance rien.) Zaru l'affiche comme "Skipped: the last run was still running" (Ignoré : la dernière exécution tournait encore).
• skipped_paused: la planification est suspendue.
• refused: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen." (L'exécution n'a pas pu démarrer. Le déclenchement enregistre la phrase du refus, par exemple une connexion requise qui n'avait pas été choisie.)

Une issue started dit que l'exécution a commencé, pas qu'elle a réussi. Le statut de l'exécution est dans execution.status, et la raison d'un échec dans ses journaux.

Étape 7. Savoir ce qui arrive quand les déclenchements échouent encore

"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'" (Quand les trois derniers déclenchements d'une planification récurrente ont tous été refusés, la planification se suspend d'elle-même, avec le motif indiqué.) Lisez paused_reason sur la planification, corrigez la cause, puis reprenez avec aegis.schedule.resume. Un déclenchement manqué pendant un redémarrage de l'orchestrateur "is still made up to 10 minutes late; later than that, the time is skipped." (est encore rattrapé jusqu'à 10 minutes en retard ; au-delà, l'heure est sautée.)

Étape 8. Les approbations s'appliquent toujours

Une exécution planifiée agit en votre nom, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too" (donc chaque appel d'outil qui attend votre approbation dans une conversation l'attend aussi dans une exécution planifiée). Dans Zaru, la demande figure sur la page Approvals avec la mention "From your schedule <name>" (depuis votre planification <nom>).

Ce que la documentation laisse ouvert

• Une commande shell. La CLI Reference ne liste aucune sous-commande de planification, donc l'auto-hébergement passe par les routes REST ou un client MCP.
• Qui est « vous » sur la pile locale. Les planifications s'exécutent en tant que personne et exigent schedule:write, alors que la pile de aegis init tourne sans IAM. La documentation ne dit pas à qui appartient une planification dans ce cas ; nous ne l'avons pas testé.

Suite

Pour placer une personne entre l'agent planifié et tout ce qu'il envoie, lisez Donner une étape d'approbation à un orchestrateur. Pour lire ce qu'a fait une exécution, lisez Lire un journal d'exécution AEGIS.

Installer AEGIS depuis 100monkeys.ai