Jusqu'ici, votre agent ne travaillait que quand quelqu'un lui demandait quelque chose. Dans la partie 5, vous lui avez confié une tâche depuis le tableau de bord et vous l'avez suivie jusqu'au bout.

Une planification supprime la demande. Vous dites une fois à AgentX quoi faire et quand, et l'agent le fait à cette heure-là, à chaque fois, que vous soyez à votre bureau ou non. Dans cette partie, vous mettez en place la plus courante : un court rapport chaque matin de semaine.

C'est la partie 6 de AgentX en pratique, une série de guides courts où chaque partie fait fonctionner une seule chose.

Ce que vous obtenez à la fin

Une planification nommée daily-report qui tourne à 8 h, heure locale, du lundi au vendredi.
La preuve qu'elle fonctionne : un rapport écrit par l'agent lors d'une exécution de test, lu sans attendre le lendemain.
Une ligne de valeur sur la tâche, pour que le tableau de bord affiche pourquoi elle tourne et cesse de la marquer look stale.

AgentX fait partie du programme produits de Noqta et reste expérimental. Sur cette version, le formulaire de planification du tableau de bord se trompe de fuseau horaire (voir l'étape 2) : ce guide passe donc par le terminal.

Prérequis

AgentX avec un agent qui fonctionne, issu de la partie 3.
AgentX 0.217.0 ou plus récent. Vérifiez avec agentx --version. Pour mettre à jour, relancez la commande d'installation de la partie 2.
Le daemon en marche (agentx daemon status affiche running) et le tableau de bord (agentx board serve), comme dans la partie 5.
Un terminal et un éditeur de texte.

Comment nous l'avons exécuté. Comme dans les parties précédentes, nous avons tout lancé dans un dossier personnel propre et séparé, sur un Mac qui fait déjà tourner un autre AgentX, avec le daemon sur le port 19021 et le tableau de bord sur le 19031. Chez vous, ce seront les valeurs par défaut, 18800 et 4202. Notre ordinateur s'appelle my-laptop et son horloge est à l'heure de Tunis, d'où Africa/Tunis dans les sorties. Notre agent était l'agent de départ Assistant (assistant) ; remplacez assistant par l'identifiant de votre agent.

Étape 1 : donner à l'agent de quoi faire un rapport

Un rapport a besoin d'une source. Une planification ne fait qu'envoyer un message à l'agent à heure fixe ; l'agent doit encore savoir où regarder. Pour ce guide, nous avons placé un petit journal de travail dans le dossier de l'agent, agents/assistant/work-log.md :

# Work log
 
## 2026-11-09
- Sent the quote to the bakery client (3 pages).
- Fixed the contact form: messages with an accent in the name were rejected.
- Still open: the hosting renewal invoice has not been paid.

En pratique, c'est ce que votre équipe tient déjà : un fichier de notes, un dossier d'exports, une liste de tickets que l'agent peut lire. L'agent travaille dans son propre dossier : placez-y le fichier ou indiquez-lui le chemin complet.

Étape 2 : choisir quand elle tourne

AgentX comprend les horaires écrits en anglais courant. Vérifiez comment il lit le vôtre avant de sauvegarder quoi que ce soit :

agentx schedule parse "weekdays at 8am"

  "weekdays at 8am"
    → 0 8 * * 1-5
    → At 08:00 AM, Monday through Friday

La deuxième ligne est le même horaire écrit en expression cron, le format à cinq champs de la plupart des planificateurs : minute, heure, jour du mois, mois, jour de la semaine. 0 8 * * 1-5 veut dire minute 0, heure 8, n'importe quel jour, n'importe quel mois, du lundi au vendredi.

D'autres formules qui marchent : every day at 8am, every monday at 10am, every 15 minutes, 1st of every month at noon. Seul l'anglais est compris : tous les jours à 8h donne Couldn't parse.

Pourquoi pas le tableau de bord ? Settings › Schedules propose un formulaire Add a schedule. Sur 0.217.0, son libellé indique une heure « in the machine's time zone » et son aperçu allait dans le même sens : nous avons tapé 0 9 * * 1 et il affichait 9 h, heure de Tunis. Mais le formulaire enregistre la planification sans fuseau horaire, et le daemon la lance alors à 9 h UTC, soit 10 h chez nous. Le terminal enregistre le fuseau avec la planification : ce que vous lisez est ce que vous obtenez.

Étape 3 : prévisualiser la planification

Écrivez maintenant la commande complète, avec --dry-run pour que rien ne soit encore enregistré :

agentx schedule "weekdays at 8am" --agent assistant --id daily-report \
  --do "Read work-log.md. Write a short report of yesterday in three lines: what was done, what is still open, and one thing to do first today." \
  --dry-run

  ✓ would add cron daily-report
    Schedule: 0 8 * * 1-5  (At 08:00 AM, Monday through Friday, Africa/Tunis)
    Agent: assistant
    On error: log

Le rôle de chaque partie :

--agent est l'agent qui fait le travail.
--id est le nom de la planification. Utilisez des minuscules, des chiffres et -. Sans lui, AgentX en invente un à partir de l'horaire et de l'agent (pour nous, weekdays-assistant).
--do est le message que l'agent reçoit à chaque fois. Dites exactement quoi lire et à quoi le rapport doit ressembler. « Trois lignes » vous donne trois lignes ; « résume » vous donne n'importe quoi.
--dry-run affiche ce qui serait enregistré et s'arrête.

Lisez la ligne Schedule:. Le nom à la fin est le fuseau horaire. Sans --timezone, AgentX prend celui de votre ordinateur. Si la machine qui fait tourner AgentX n'est pas à la même heure que vous, un serveur par exemple, ajoutez votre fuseau :

agentx schedule "weekdays at 8am" --agent assistant --id daily-report \
  --do "..." --timezone Asia/Riyadh --dry-run

  ✓ would add cron daily-report
    Schedule: 0 8 * * 1-5  (At 08:00 AM, Monday through Friday, Asia/Riyadh)

Utilisez le nom complet du fuseau, comme Asia/Riyadh, Africa/Tunis ou Europe/Paris. Un nom court comme Tunis est accepté ici mais échoue plus tard (voir Dépannage).

Étape 4 : l'enregistrer

Relancez la même commande sans --dry-run :

  ✓ Added cron daily-report
    Schedule: 0 8 * * 1-5  (At 08:00 AM, Monday through Friday, Africa/Tunis)
    Agent: assistant
    On error: log
    Daemon hot-reloaded.

Daemon hot-reloaded. signifie que le daemon en marche a pris la nouvelle planification tout de suite. Aucun redémarrage n'est nécessaire. La planification est enregistrée dans agentx.json, sous crons :

"daily-report": {
  "enabled": true,
  "schedule": "0 8 * * 1-5",
  "timezone": "Africa/Tunis",
  "agent": "assistant",
  "prompt": "Read work-log.md. Write a short report of yesterday in three lines: ...",
  "timeout": 600,
  "onError": ["log"]
}

Listez vos planifications pour vérifier :

agentx schedule list

  ● daily-report                     0 8 * * 1-5    → assistant
      At 08:00 AM, Monday through Friday (Africa/Tunis)

Le point ● signifie qu'elle est active. Une planification désactivée affiche ○.

Étape 5 : la tester sans attendre demain

AgentX 0.217.0 n'a pas de bouton « lancer maintenant » pour une planification. Le moyen rapide d'en tester une est une copie qui tourne toutes les deux minutes, avec le même agent et le même message :

agentx schedule "every 2 minutes" --agent assistant --id report-test \
  --do "Read work-log.md. Write a short report of yesterday in three lines: what was done, what is still open, and one thing to do first today."

  ✓ Added cron report-test
    Schedule: */2 * * * *  (Every 2 minutes, Africa/Tunis)
    Agent: assistant
    On error: log
    Daemon hot-reloaded.

Attendez la prochaine minute paire. Notre première exécution a démarré à la minute pile et s'est terminée 13 secondes plus tard. Ensuite, supprimez la copie tout de suite, sinon elle continue toutes les deux minutes et consomme votre compte de modèle à chaque fois :

agentx schedule remove report-test

  ✓ report-test removed
    Daemon hot-reloaded.

Étape 6 : lire le rapport

Chaque exécution est conservée dans un petit fichier de votre dossier AgentX, sous .agentx/cron/runs/<nom de la planification>/, un fichier par exécution, nommé d'après son heure de départ. Ouvrez le plus récent :

ls -t .agentx/cron/runs/report-test | head -1

2026-11-10T09-08-00-002Z.json

Le rapport se trouve dans "response", et "success": true indique que l'exécution s'est bien passée. Le nôtre disait :

**Yesterday (2026-11-09):**
- **Done:** Sent a 3-page quote to the bakery client; fixed the contact form bug that rejected names with accents.
- **Still open:** Hosting renewal invoice has not been paid.
- **First thing today:** Follow up on the hosting renewal invoice to avoid a service interruption.

Tout vient du journal de l'étape 1 : vous pouvez vérifier chaque ligne. Si une ligne ne figure pas dans la source, rendez le message plus strict, par exemple « utilise uniquement ce qui est dans work-log.md ».

Le tableau de bord vous dit si une exécution a marché, pas ce qu'elle a dit. Ouvrez http://127.0.0.1:4202/mesh, choisissez l'onglet Operations, puis votre planification sous Routines :

Le volet de la routine report-test dans Operations : état enabled, planification toutes les deux minutes, fuseau Africa/Tunis, dernière exécution success à 10:08, échecs consécutifs 0, exécutions inspectées 3

Last run, Failures in a row et Next fire sont les trois lignes à lire. Activity liste aussi chaque exécution comme from a job, mais sur 0.217.0 sa page Open the run affiche une conversation vide marquée HTTP 404, comme dans la partie 5. Le texte se trouve dans le fichier.

Pour recevoir le rapport au lieu d'aller le chercher, une planification peut publier chaque réponse dans une discussion, Telegram par exemple, avec --notify. Il faut pour cela un canal connecté, ce qui est l'objet de la partie 4 de la série ; nous ne l'avons donc pas testé ici.

Étape 7 : donner une ligne de valeur à la tâche

Ouvrez Jobs dans le menu du tableau de bord. Chaque tâche récurrente y figure avec sa planification, ses sept dernières exécutions sous forme de carrés et son état. Une planification toute neuve est marquée look stale, avant même d'avoir tourné :

La page Jobs : daily-report avec ses lignes Why et Proves it, planification 0 8 * * 1-5 et état on ; report-test sans ligne de valeur, sans objectif et marqué look stale

Look stale veut dire l'une de trois choses : la tâche est désactivée depuis 14 jours ou plus, elle a échoué trois fois de suite, ou elle n'a pas de ligne de valeur. Une ligne de valeur dit pourquoi la tâche tourne et quel chiffre prouve qu'elle en vaut la peine. AgentX ne mesure pas ce chiffre ; il est là pour que celui qui lit la liste puisse se demander « est-ce que ça vaut encore le coup ? ».

La commande du terminal n'a pas d'option pour cela : ajoutez-la dans agentx.json. Faites-le en dernier : relancer agentx schedule avec le même --id remplace toute l'entrée et efface la ligne de valeur. Trouvez daily-report sous crons et ajoutez un bloc value :

"daily-report": {
  "enabled": true,
  "schedule": "0 8 * * 1-5",
  "timezone": "Africa/Tunis",
  "agent": "assistant",
  "prompt": "Read work-log.md. ...",
  "timeout": 600,
  "onError": ["log"],
  "value": {
    "why": "Starts each weekday with what is done and what is still open",
    "metric": "Open items carried more than 2 days: 0"
  }
}

Enregistrez le fichier. Le daemon le relit tout seul. Sur la page Jobs, daily-report affiche maintenant les lignes Why et Proves it, et son état passe à on. L'étiquette no goal en dessous est un lien séparé et facultatif vers un objectif ; elle ne rend pas la tâche « stale ».

Settings › Schedules montre les mêmes tâches avec leur message et leur ligne de valeur, et un bouton Delete pour chacune :

Settings, Schedules : daily-report avec son message et sa ligne de valeur, report-test sans ligne de valeur, et le formulaire Add a schedule en dessous

Vérifier que ça marche

agentx schedule list affiche ● daily-report avec Monday through Friday et votre fuseau horaire entre parenthèses.
report-test a disparu de la liste.
.agentx/cron/runs/report-test/ contient au moins une exécution avec "success": true et un rapport que vous pouvez comparer à votre source.
Jobs dans le tableau de bord affiche daily-report comme on, avec ses lignes Why et Proves it et next in le bon nombre d'heures.
Le jour ouvré suivant après 8 h, .agentx/cron/runs/daily-report/ contient son premier fichier.

Dépannage

Couldn't parse: "..." L'horaire n'est pas sous une forme connue d'AgentX. Écrivez en anglais, avec l'une des formes suggérées par le message, comme every morning at 9 ou daily at 9:30am. Testez d'abord avec agentx schedule parse.

Agent "reporter" not found in agentx.json suivi de Available: assistant. Utilisez l'un des identifiants de la deuxième ligne.

La planification est dans la liste mais ne tourne jamais. Cherchez Failed to schedule dans le journal du daemon. Nous avons vu Failed to schedule "tz-test": Invalid time zone specified: Tunis : la commande avait accepté le nom de fuseau court, mais le daemon l'a refusé. Relancez la commande avec le même --id et un nom complet comme Africa/Tunis. La nouvelle entrée remplace entièrement l'ancienne, sans avertissement : ajoutez ensuite à nouveau la ligne de valeur de l'étape 7. Vérifiez aussi que le daemon tourne (agentx daemon status) et que la planification affiche ● (sinon, agentx schedule on daily-report).

Elle a tourné une heure trop tôt ou trop tard. La planification a le mauvais fuseau, ou aucun. Regardez le nom entre parenthèses dans agentx schedule list. Une planification créée avec le formulaire du tableau de bord n'a pas de fuseau et tourne en UTC. Recréez-la depuis le terminal.

La copie de test continue de tourner. Supprimez-la : agentx schedule remove report-test. Pour mettre une planification en pause sans la supprimer, utilisez agentx schedule off <nom> puis agentx schedule on <nom>.

Le nom a été accepté avec des espaces ou des majuscules. 0.217.0 a accepté --id "Bad Name". Utilisez quand même des minuscules et - : les autres commandes et le tableau de bord désignent les planifications par ce nom.

L'exécution a échoué. Ouvrez le fichier le plus récent de .agentx/cron/runs/<nom>/ : "success": false est accompagné de l'erreur. Un problème de connexion au modèle se présente comme dans la partie 3.

Suite de la série

La suite : votre premier workflow, où plusieurs étapes s'enchaînent au lieu d'un seul message. Mettre votre agent sur Telegram est la partie 4 et viendra séparément ; c'est aussi là qu'une planification apprend à envoyer son rapport sur votre téléphone. En attendant, la documentation d'AgentX se trouve sur github.com/anis-marrouchi/agentx.

Conclusion

Vous avez confié à un agent un travail qu'il fait désormais seul : chaque jour de semaine à 8 h, heure locale, il lit le journal de travail et écrit trois lignes. Vous avez vérifié le fuseau avant d'enregistrer, testé la tâche avec une copie toutes les deux minutes au lieu d'attendre un jour, lu le vrai rapport et donné à la tâche une ligne de valeur, pour que le tableau de bord vous dise si elle cesse un jour d'en valoir la peine.

Si vous voulez des rapports comme celui-ci mis en place et suivis pour votre entreprise, parlez-nous.