Configurer ses premiers agents OpenClaw : JARVIS, HERMÈS et CHRONOS

Un agent IA généraliste, c'est comme demander à un seul employé de gérer l'infrastructure, les emails, le calendrier et la rédaction simultanément. Ça fonctionne… jusqu'à ce que ça ne fonctionne plus. La spécialisation n'est pas un luxe : c'est l'architecture qui détermine la fiabilité à long terme.

Ce billet est le cinquième d'une série de 7 sur le déploiement OpenClaw chez BOTUM. Les billets précédents ont couvert le concept, l'installation, la sécurité et la gestion des secrets. Ici, on entre dans le concret : comment configurer trois agents spécialisés, les faire coexister dans un workspace partagé, et les faire collaborer sans qu'ils se marchent dessus.

1. Pourquoi spécialiser ses agents

La tentation initiale est forte : un seul agent, une seule config, une seule session. Simple à démarrer, mais problématique à l'échelle.

Un agent généraliste accumule des instructions qui finissent par se contredire. Il jongle entre des contextes hétérogènes — email, code, calendrier, monitoring — dans une seule fenêtre de contexte qui se sature. Quand la compaction arrive, des informations importantes tombent. Le comportement devient imprévisible.

La spécialisation répond à trois problèmes concrets :

• Contexte ciblé : un agent email ne charge que les règles et l'historique liés à l'email. Son contexte reste léger, pertinent, prévisible.
• Périmètre défini : l'agent ne peut pas — par conception — faire des actions hors de son domaine. Le risque d'effet de bord involontaire est réduit structurellement.
• Maintenance indépendante : on peut modifier les règles de l'agent calendrier sans toucher à l'agent email. Les changements sont isolés et traçables.

Selon une analyse interne BOTUM menée sur 6 mois d'exploitation, un réseau de 5 agents spécialisés traite 3,4× plus de tâches par jour qu'un agent généraliste équivalent, avec un taux d'erreur divisé par 2,7. La spécialisation n'est pas une complexité supplémentaire : c'est une simplification distribuée.

2. L'architecture multi-agents : workspace partagé, identités distinctes

Tous les agents OpenClaw d'un même déploiement partagent un workspace commun — un répertoire Git versionné. C'est leur terrain commun : ils y lisent, y écrivent, y communiquent.

Mais chaque agent a une identité distincte, définie par deux fichiers clés :

AGENTS.md — la carte d'identité collective

Ce fichier décrit le réseau complet : qui fait quoi, quels agents existent, leurs responsabilités, leurs canaux de communication. Chaque agent le lit en début de session pour comprendre l'écosystème dans lequel il opère et savoir à qui déléguer quand une tâche dépasse son périmètre.

SOUL.md — la personnalité partagée

Ce fichier définit la voix, le ton et les valeurs communes à tous les agents. Directivité, style de communication, règles de sécurité générales. C'est le contrat de base de tous les agents du réseau.

Fichiers de rôle spécifiques

Chaque agent a son propre répertoire dans agents/ du workspace. Il y stocke ses règles métier, son historique spécifique, ses fichiers de configuration. Un agent email maintient ses règles de filtrage dans agents/hermes/rules.md. Un agent système maintient sa checklist de santé dans agents/jarvis/healthcheck.md.

Mémoire partagée vs mémoire isolée

La mémoire long terme dans MEMORY.md et les notes quotidiennes dans memory/YYYY-MM-DD.md sont accessibles à tous les agents. C'est la mémoire institutionnelle du réseau. Mais chaque agent maintient aussi sa mémoire isolée dans son répertoire — contexte opérationnel qui n'a pas vocation à polluer l'espace commun.

3. Agent JARVIS — le gardien de l'infrastructure

JARVIS est l'agent système. Son périmètre : tout ce qui touche à la santé de l'infrastructure, à la gestion du workspace et à la continuité opérationnelle du réseau d'agents.

Responsabilités

• Monitoring santé : vérification périodique des services Docker, des processus critiques, de l'espace disque, de la latence réseau.
• Git commits automatiques : commit régulier des changements dans le workspace pour garantir la traçabilité. Aucune donnée ne disparaît sans trace.
• Mémoire long terme : JARVIS est responsable de la consolidation de la mémoire quotidienne vers MEMORY.md. Il identifie ce qui mérite d'être retenu à long terme et élimine le bruit.
• Compactions de contexte : quand la fenêtre de contexte d'un agent approche de sa limite, JARVIS déclenche une compaction propre — extraction des informations critiques avant perte.
• Alertes proactives : JARVIS envoie des notifications à la messagerie si un seuil critique est atteint (service down, espace disque critique, erreur répétée).

Configuration type

Le fichier agents/jarvis/ROLE.md définit son comportement :

# JARVIS — Agent Système
## Périmètre
- Infrastructure Docker (us-srv-dck-01)
- Workspace Git (read/write)
- Monitoring santé (crons système)
- Compactions de contexte

## Règles
- Commit git toutes les 4h si changements
- Alerte messagerie si service down > 5 min
- Consolider memory/ → MEMORY.md chaque dimanche 23h
- Ne jamais modifier les fichiers de rôle des autres agents
- Ne jamais envoyer d'emails à des tiers

## Crons
- 08:00 : santé infra complète
- 20:00 : commit workspace + log quotidien
- Dimanche 23:00 : consolidation mémoire

La règle clé : JARVIS a un accès élargi au workspace, mais des restrictions explicites sur les actions externes. Il peut lire tous les fichiers de tous les agents, mais ne peut pas modifier les règles des autres sans instruction explicite.

4. Agent HERMÈS — le pipeline email

HERMÈS est l'agent email. Son périmètre : tout ce qui traverse l'inbox — lecture, classification, digests, réponses standardisées, transferts conditionnels.

Responsabilités

• Lecture inbox IMAP : connexion sécurisée à la boîte email via IMAP/SSL. Lecture des emails entrants sans téléchargement intempestif.
• Classification intelligente : chaque email entrant est catégorisé — client, prospect, partenaire, newsletter, spam, urgence. La classification alimente une queue de tâches.
• Digests quotidiens : à 8h du matin, HERMÈS génère un digest structuré des emails de la veille et de la nuit — résumé, priorités, actions requises.
• Règles de filtrage métier : certains emails déclenchent des actions automatiques — notifier un autre agent, créer une tâche, archiver.
• Réponses standardisées : pour les cas définis (accusé de réception, confirmation de rendez-vous), HERMÈS peut envoyer des réponses via SMTP.

Intégration IMAP/SMTP

La configuration de connexion est stockée dans le vault (voir Billet 4 de la série). HERMÈS récupère les credentials au runtime via le helper vault — jamais en dur dans sa config.

# agents/hermes/ROLE.md
## Connexions
- IMAP : récupéré depuis vault (clé: imap-botum)
- SMTP : récupéré depuis vault (clé: smtp-botum)

## Règles de classification
- Objet contient "URGENT" → priorité P1, notification immédiate messagerie
- Expéditeur dans liste VIP → digest prioritaire
- Newsletter/promo → archive automatique
- Facture/paiement → notifier LEDGER via queue

## Digest
- Heure : 08:00 quotidien
- Format : résumé, nb emails, top 3 priorités, actions requises
- Destination : messagerie habituelle

Ce que HERMÈS ne fait pas

HERMÈS ne prend pas de décisions sur les actions hors de son périmètre. S'il reçoit un email concernant la facturation, il crée une entrée dans la queue de tâches pour LEDGER. S'il reçoit une demande de publication de contenu, il notifie CYRANO. Il classe et délègue — il n'usurpe pas.

5. Agent CHRONOS — l'architecte du temps

CHRONOS est l'agent calendrier. Son périmètre : consultation et mise à jour de Google Calendar, génération de briefings, coordination des rappels entre agents.

Responsabilités

• Briefing matinal : à 8h15, CHRONOS consulte le calendrier des 48 prochaines heures et génère un briefing structuré — réunions, deadlines, conflits potentiels.
• Consultation à la demande : CHRONOS répond aux requêtes des autres agents sur les disponibilités, les créneaux libres, les événements à venir.
• Mise à jour calendrier : sur instruction (via messagerie ou queue de tâches), CHRONOS peut créer, modifier ou supprimer des événements.
• Coordination des rappels : CHRONOS informe les autres agents des événements qui les concernent — une deadline de publication pour CYRANO, une réunion client pour NEXUS.

Intégration Google Calendar API

CHRONOS utilise l'API Google Calendar v3 via OAuth 2.0. Les credentials OAuth sont dans le vault, le token de refresh est stocké de façon sécurisée.

# agents/chronos/ROLE.md
## Calendrier cible
- ID calendrier : récupéré depuis vault (clé: gcal-primary)

## Briefing matinal
- Heure : 08:15 quotidien
- Fenêtre : J+0 à J+2
- Format : liste réunions, deadlines, conflits signalés
- Destination : messagerie habituelle

## Règles
- Événements "CONFIDENTIEL" → ne pas inclure dans les résumés partagés
- Conflits < 30 min de préavis → alerte P1
- Créer événements uniquement sur instruction explicite

## Coordination inter-agents
- Deadline publication → notifier CYRANO (J-1)
- Réunion client → notifier NEXUS (J-1)
- Facture due → notifier LEDGER (J-2)

6. Protocoles de communication inter-agents

Les agents ne communiquent pas en temps réel. Ils communiquent via des artefacts persistants dans le workspace — fichiers JSON, files de tâches, états partagés.

La queue de tâches

Le fichier queue/tasks.json est le canal de communication principal entre agents. Un agent producteur y dépose une tâche, un agent consommateur la lit à sa prochaine exécution.

// queue/tasks.json (exemple)
[
  {
    "id": "task-2026-03-14-001",
    "from": "hermes",
    "to": "ledger",
    "type": "invoice_received",
    "priority": "normal",
    "payload": {
      "sender": "client@exemple.com",
      "subject": "Facture #2026-031",
      "received_at": "2026-03-14T07:43:00Z"
    },
    "status": "pending",
    "created_at": "2026-03-14T07:43:12Z"
  }
]

Les artefacts partagés

Pour les échanges de données volumineuses, les agents utilisent des artefacts dans le dossier artifacts/. HERMÈS peut y déposer un export structuré de l'inbox. CHRONOS y dépose son briefing journalier sous forme JSON pour que d'autres agents puissent le consommer.

Les triggers

Certains événements déclenchent des actions en cascade. CHRONOS détecte une deadline de publication demain → dépose un trigger dans triggers/ → CYRANO le lit à sa prochaine session et génère le contenu manquant. Le trigger contient les métadonnées nécessaires (slug, langue, deadline) sans nécessiter d'interaction humaine.

7. Erreurs à éviter

Les équipes BOTUM ont identifié trois catégories d'erreurs récurrentes lors du déploiement d'un réseau multi-agents :

Périmètres qui se chevauchent

Si deux agents ont tous les deux la responsabilité de "gérer les emails urgents", ils produiront deux réponses pour le même email. La règle : un seul agent responsable par domaine, sans exception. Les zones grises doivent être résolues dans AGENTS.md, pas laissées à l'appréciation de chaque agent.

Conflits de mémoire

Si HERMÈS et JARVIS écrivent tous les deux dans MEMORY.md sans coordination, on obtient des entrées contradictoires ou redondantes. La règle : un seul agent (JARVIS dans notre architecture) est propriétaire de la mémoire long terme. Les autres déposent des notes dans memory/YYYY-MM-DD.md ; JARVIS consolide.

Boucles infinies de tâches

Scénario classique : HERMÈS dépose une tâche pour CHRONOS, CHRONOS dépose une tâche pour HERMÈS qui déclenche à nouveau la même tâche. La règle : chaque tâche dans la queue doit avoir un statut final explicite (done, failed, skipped) et les agents doivent vérifier qu'une tâche n'existe pas déjà avant d'en créer une similaire.

Règle BOTUM : avant chaque déploiement d'un nouvel agent, cartographier exhaustivement ses interactions potentielles avec les agents existants. Une heure de conception évite une semaine de débogage.

8. Une journée type avec les 3 agents actifs

Pour illustrer concrètement, voici le déroulement d'une journée type dans le déploiement BOTUM :

• 07:43 — HERMÈS lit l'inbox nocturne. 12 emails. 1 urgence (facture impayée), 3 prospects, 8 newsletters. Dépose une tâche pour LEDGER dans la queue. Archive les newsletters.
• 08:00 — JARVIS vérifie la santé de l'infra. Tous les services nominaux. Commit workspace git avec les changements de la nuit.
• 08:15 — CHRONOS génère le briefing matinal : 2 réunions aujourd'hui, deadline publication blog demain. Envoie le briefing sur la messagerie habituelle. Dépose un trigger pour CYRANO (deadline demain).
• 09:30 — ARGUS (agent veille) dépose son rapport hebdo dans artifacts/. JARVIS le détecte et notifie via messagerie.
• 12:00 — HERMÈS traite le batch de la matinée. 5 nouveaux emails. 1 réponse standardisée envoyée (accusé de réception prospect). 1 tâche créée pour NEXUS (suivi LinkedIn lead).
• 16:00 — CYRANO, alerté par le trigger de CHRONOS, commence la rédaction du billet à publier demain. Draft déposé dans artifacts/drafts/.
• 20:00 — JARVIS commit final. Consolide les logs de la journée dans memory/2026-03-14.md. Rapporte le résumé opérationnel du jour via messagerie.

Pas d'intervention humaine requise sur ces 12h. Chaque agent a opéré dans son périmètre, communiqué via les canaux définis, laissé des traces auditables.

Conclusion

La configuration de JARVIS, HERMÈS et CHRONOS représente le socle opérationnel minimum d'un réseau d'agents OpenClaw. Ces trois agents couvrent les domaines fondamentaux de toute organisation : l'infrastructure, la communication, et le temps.

La vraie difficulté n'est pas technique — c'est organisationnelle. Définir des périmètres clairs, établir des protocoles de communication sans ambiguïté, et résister à la tentation d'ajouter des responsabilités "temporaires" qui finissent par devenir permanentes et conflictuelles.

Une fois ces trois agents stabilisés, le réseau devient extensible sans friction. Chaque nouvel agent s'intègre dans un écosystème déjà structuré, avec des conventions claires et des canaux de communication établis.

→ Billet 6 : OpenClaw vs ChatGPT vs Claude API : quel outil pour quel usage en enterprise ?