Chaîner des crons Hermes avec context_from sans croire à une synchronisation magique

Tu as deux jobs cron dans Hermes. Le premier récupère des données, le deuxième produit un résumé. Tu veux que le deuxième lise la sortie du premier. Jusque-là, rien d’anormal. Si tu découvres les routines cron Hermes, commence par là avant de chaîner des jobs.

Hermes propose context_from pour ça. Tu listes le nom du job upstream, et le job downstream reçoit sa dernière sortie en contexte. Le mécanisme est simple, la doc est claire. Mais il y a un piège que beaucoup découvrent après coup : context_from ne synchronise rien. Il lit. Point.

Si tu construis ta chaîne en pensant que les jobs s’exécutent dans l’ordre juste parce que tu les as déclarés dans le bon sens, tu vas avoir des surprises. Cet article explique comment context_from fonctionne vraiment, où il peut te lâcher, et comment tester ta chaîne avant de lui confier un vrai workflow.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Ce que context_from fait vraiment

context_from est un paramètre du job cron. Tu lui passes une liste de noms (ou d’IDs) de jobs, et au moment où ton job s’exécute, Hermes injecte la sortie complétée la plus récente de chaque job référencé au-dessus du prompt.

Voici un exemple réel, tiré de la documentation officielle :

cronjob(action="create", name="daily-digest",
 schedule="every day 7am",
 context_from=["ai-news-fetch", "github-prs-fetch"],
 prompt="Write the daily digest using the outputs above.")

Le job daily-digest reçoit les dernières sorties de ai-news-fetch et github-prs-fetch. Pas leur sortie en cours. Pas une promesse qu’ils viennent de finir. Juste le dernier fichier .md stocké dans ~/.hermes/cron/output/{job_id}/.

C’est un lecteur de historique, pas un orchestrateur.

La doc est explicite sur ce point. Elle dit que context_from « reads the most recent completed output, it does not wait for upstream jobs that are running in the same tick. » Cette phrase change tout si tu conçois ta chaîne comme un pipeline.

Le piège du même tick

Le scheduler Hermes tick toutes les 60 secondes. Il regarde quels jobs sont dus, et les lance. Les jobs sans workdir partent en parallèle. Ceux avec workdir passent en séquentiel.

Imagine ce scénario :

• Job A : every hour (fetch des données)
• Job B : every day 7am (digest basé sur A, avec context_from=["job-a"])

À 7h00, le scheduler voit que A et B sont dus. Il les lance tous les deux. B démarre, appelle context_from, et récupère la dernière sortie complétée de A. Sauf que cette sortie date de 6h00, parce que le run de 7h00 de A est encore en cours.

Résultat : B produit un digest basé sur des données qui ont une heure de retard. Aucun warning. Aucune erreur. Juste un résultat périmé.

Ce piège est d’autant plus sournois qu’il est intermittent. Si le job A finit en 10 secondes et que B met 15 secondes à démarrer, B lira la bonne sortie. Mais si A prend 45 secondes ce jour-là (plus de données, latence réseau), B lira la sortie précédente. Ta chaîne fonctionne 9 fois sur 10, et la 10e fois elle produit un résultat faux sans prévenir.

Comment tester une chaîne avant de lui faire confiance

Avant de mettre une chaîne de crons en production, voici les étapes pour vérifier qu’elle tient :

1. Lance les jobs manuellement d’abord. Utilise hermes cron run <job_id> pour exécuter A, attendre qu’il finisse, puis lancer B. Vérifie que B reçoit bien la sortie de A.
2. Teste le scénario du même tick. Programme A et B à la même minute (ex: 0 9 * * * pour les deux). Lance un hermes cron tick manuel et observe si B lit la sortie du run en cours ou la précédente.
3. Ajoute un décalage explicite. Si ton workflow tolère un délai d’une minute, décale B d’une minute après A (1 9 * * * au lieu de 0 9 * * *). C’est la solution la plus simple et la plus fiable.
4. Utilise un script pre-run gate si le décalage fixe ne suffit pas. Un script dans ~/.hermes/scripts/ peut vérifier qu’un fichier de sortie attendu existe avant d’autoriser le job downstream. Le script renvoie {"wakeAgent": true} ou {"wakeAgent": false}.
5. Surveille les sorties. Les fichiers de sortie sont dans ~/.hermes/cron/output/{job_id}/{timestamp}.md. Vérifie les timestamps après quelques runs pour confirmer que l’enchaînement est cohérent.

Ces cinq vérifications prennent dix minutes. Elles t’évitent de découvrir le problème trois semaines plus tard dans un rapport client.

context_from ou Kanban : comment choisir

La question n’est pas « lequel est le meilleur ». La question est « est-ce que mon workflow tolère un délai d’un tick entre les étapes ».

Critère	context_from (cron)	Kanban
Mécanisme	Lecture du dernier fichier de sortie complété	File de messages durable avec state machine
Garantie d’ordre	Aucune dans le même tick	Un job downstream ne démarre que quand l’upstream est terminé
Résistance aux pannes	Si A échoue, B lit l’avant-dernière sortie sans le savoir	Si A échoue, B reste bloqué jusqu’à ce que A réussisse
Complexité de mise en place	Une ligne dans la config du job	Création de tâches, assignation de profils, dispatch
Quand l’utiliser	Un délai d’un tick est acceptable ; les jobs sont indépendants	Une étape doit attendre la fin de la précédente ; intervention humaine possible

context_from est parfait pour un job de digest quotidien qui agrège des données fetchées toutes les heures. Le décalage d’une heure sur un résumé quotidien est négligeable.

Kanban devient nécessaire quand l’étape 2 ne peut pas démarrer sans le résultat exact de l’étape 1. Par exemple : un job d’analyse qui doit attendre qu’un job de collecte ait fini, puis un job de publication qui doit attendre l’analyse. Dans ce cas, chaque tâche Kanban est créée par la précédente une fois son travail terminé.

La doc officielle résume bien la différence : delegate_task est un appel de fonction, Kanban est une file de travail où chaque passage de relais est une ligne que n’importe quel profil (ou humain) peut lire et modifier. context_from, lui, est encore plus simple : c’est un lecteur de fichier. Si tu veux comprendre comment ces briques s’articulent dans un workflow agent multi-étape, j’ai détaillé les patterns de coordination dans un article dédié.

Ce qui reste vrai

context_from n’est pas cassé. Il fait exactement ce que la doc promet : lire la dernière sortie complétée. Le problème survient quand on attend de lui une synchronisation qu’il n’a jamais prétendu fournir.

Si ta chaîne de crons tolère un décalage d’un tick, context_from est l’outil le plus léger et le plus direct. Si tu as besoin qu’une étape attende vraiment la fin de la précédente, le Kanban Hermes est la bonne réponse.

Pour creuser les patterns de coordination multi-agents et apprendre à architecturer des workflows qui tiennent dans la durée, tu peux faire une demande d’accès au Second Cerveau Kavyro. On y couvre les vrais cas, pas les démos.