J'ai Donné un Cerveau Partagé à Mes Agents OpenClaw. Ils Ont Arrêté d'Être Stupides.

Les agents OpenClaw sont puissants. Mais quand tu en lances plusieurs, ils deviennent souvent sourdents. Oracle trouve un mot-clé génial, Flash écrit un article sur un sujet complètement différent, Alfred propose une stratégie qui ignore les deux. Trois employés brillants… dans des chambres insonorisées.

La solution ? Un cerveau partagé. Une Architecture qui a transformé mes 3 agents d’intelligences isolées en une équipe coordonnée. Et le plus fou ? Ça prend 20 minutes à mettre en place. Pas de LangChain, pas de framework complexe. Juste des symlinks et des fichiers Markdown.

Le Problème : des Agents Sourdents

J’avais 3 agents spécialisés :

• Oracle (SEO) : analyse GSC/GA4, trouve des opportunités mots-clés
• Flash (Content) : repurposise mes podcasts, écrit en mon style
• Alfred (Stratégie) : digest matinal, coordination système

Chaque agent tournait sur ses crons. Résultat ? Des insights qui restaient dans un rapport, du contenu hors-sujet, des stratégies qui ignoraient les découvertes des autres.

La Solution : un Répertoire Partagé

L’idée est d’un point de convergence unique où chaque agent peut lire les outputs des autres et écrire ses propres insights. Tous les agents symlinkent ce dossier dans leur workspace → même inode, même fichier.

1
shared-context/
2
├── priorities.md          ← Priorités courantes (depuis les stand-up voice)
3
├── agent-outputs/         ← Chaque agent dépose son travail ici
4
│   ├── oracle-seo-YYYY-MM-DD.md
5
│   ├── flash-content-YYYY-MM-DD.md
6
│   └── alfred-digest-YYYY-MM-DD.md
7
├── feedback/              ← Mes validations/rejets (flux vers TOUS les agents)
8
├── kpis/                  ← Métriques live (trafic, conversions)
9
├── calendar/              ├── Réunions du jour, contacts pertinents
10
├── content-calendar/      ← Planifié, publié, gaps
11
└── roundtable/            ← Synthèse cross-agent quotidienne

Mise en Place Technique (20 minutes)

1. Créer le dossier partagé (sur le host ou un volume Docker) :

sudo mkdir -p /opt/openclaw/shared-context
sudo chown -R 1000:1000 /opt/openclaw/shared-context  # UID/GID de l'agent

2. Dans chaque config d’agent, ajouter un volume bind :

1
{
2
  "agents": {
3
    "oracle": {
4
      "sandbox": {
5
        "docker": {
6
          "volumes": [
7
            "/opt/openclaw/shared-context:/workspace/shared-context:rw"
8
          ]
9
        }
10
      }
11
    }
12
  }
13
}

3. Ou, si workspace sur le host, simplement symlink :

cd /path/to/oracle/workspace
ln -s /opt/openclaw/shared-context shared-context

cd /path/to/flash/workspace
ln -s /opt/openclaw/shared-context shared-context

cd /path/to/alfred/workspace
ln -s /opt/openclaw/shared-context shared-context

Vérification : ls -i shared-context/priorities.md doit donner le même inode dans les trois workspaces.

Comment Ça Marche en Pratique

Exemple concret

7:00 AM - Oracle (SEO) tourne :

• Scrape GSC, trouve un mot-clé “reddit marketing agency” avec 17,5% de conversion
• Écrit dans shared-context/agent-outputs/oracle-seo-2025-02-10.md

7:30 AM - Flash (Content) tourne :

• Lit le fichier d’Oracle
• Voir l’opportunité Reddit → crée un contenu “Comment utiliser Reddit pour générer des leads B2B”
• Publie sur WordPress, enregistre sa sortie dans agent-outputs/flash-content-...

8:45 AM - Alfred (Stratégie) tourne :

• Lit les outputs d’Oracle et Flash
• Synthétise : “On capitalise sur Reddit cette semaine, ajoute 2 posts supplémentaires”
• Écrit le digest dans roundtable/2025-02-10-synthesis.md
• Met à jour priorities.md pour le lendemain

Tout est lié. Aucune information ne se perd.

Implémentation OpenClaw Complète

Voici un config complète pour 3 agents :

1
{
2
  "agents": {
3
    "oracle": {
4
      "workspace": "/opt/openclaw/oracle",
5
      "model": "openrouter/stepfun/step-3.5-flash:free",
6
      "sandbox": {
7
        "mode": "non-main",
8
        "docker": {
9
          "image": "openclaw-sandbox:latest",
10
          "volumes": [
11
            "/opt/openclaw/shared-context:/workspace/shared-context:rw"
12
          ]
13
        }
14
      },
15
      "cron": "0 7 * * *"
16
    },
17
    "flash": {
18
      "workspace": "/opt/openclaw/flash",
19
      "model": "openrouter/stepfun/step-3.5-flash:free",
20
      "sandbox": {
21
        "mode": "non-main",
22
        "docker": {
23
          "volumes": [
24
            "/opt/openclaw/shared-context:/workspace/shared-context:rw"
25
          ]
26
        }
27
      },
28
      "cron": "0 7:30 * * *"
29
    },
30
    "alfred": {
31
      "workspace": "/opt/openclaw/alfred",
32
      "model": "openrouter/stepfun/step-3.5-turbo",
33
      "sandbox": {
34
        "mode": "non-main",
35
        "docker": {
36
          "volumes": [
37
            "/opt/openclaw/shared-context:/workspace/shared-context:rw"
38
          ]
39
        }
40
      },
41
      "cron": "0 8:45 * * *"
42
    }
43
  }
44
}

Script de Lancement Automatique

Pour chaque agent, un petit script qui sync le contexte et lance le cron :

#!/bin/bash
cd /opt/openclaw/oracle
# S'assurer que shared-context existe
ln -sf /opt/openclaw/shared-context shared-context
# Lancer l'agent
openclaw agent --message "Mission quotidienne SEO" --to oracle

Programme avec cron ou openclaw cron add.

Avantages Insider

• Transparence totale : tu peux ouvrir un fichier et voir ce que chaque agent a fait
• Debug facile : si un agent déraille, tu vois où il a écrit n’importe quoi
• Extensible : ajouter un 4ème agent = juste un symlink
• Sans réseau : pas d’API inter-agents, juste du FS (fiable, rapide)
• Humain-in-the-loop : tu peux écrire dans feedback/ pour corriger un agent

Le Vrai Secret : la Boucle de Feedback

L’astuce qui a tout changé ? Les boutons approve/reject. Chaque output d’agent inclut des boutons d’approbation. Quand tu rejettes quelque chose — “pas assez haut niveau” — ce rejet est écrit dans shared-context/feedback/. Tous les agents lisent ces反馈. En 2 semaines, 16 décisions ont appris à toute l’équipe :

• Oracle a arrêté de recommander des keywords “tool-query” (je les rejetais)
• Flash sait maintenant quels angles de contenu j’approuve
• Alfred ajuste ses synthèses en fonction de mes rejets

Un seul humain, une décision, 3 agents qui apprennent. C’est l’effet de levier multiplicatif.

Priorités par Voice Note

Je fais un stand-up vocal de 90 secondes chaque matin. Alfred (le curator) transcrit la note, met à jour shared-context/priorities.md. Au prochain run, chaque agent pondère ses actions selon ces priorités.

Exemple : je dis “Cette semaine on se concentre sur Reddit”. Oracle va chercher des keywords Reddit, Flash va créer du contenu Reddit, Alfred va prioriser les tâches en conséquence.

Résultat : une voix, trois agents réalignés. Pas de Slack, pas de réunion, pas de “je te loop”.

Architecture à Grande Échelle

10 agents

Ajouter un agent = un symlink + mise à jour de ses instructions (“Lis shared-context/ avant chaque action”). La structure gère naturellement :

• Priorités cascade : le nouveau agent lit les mêmes priorités
• Feedback composé : les rejets enseignent aussi le nouveau
• Signaux croisés : plus d’agents = plus de patterns détectés
• Un curator (Alfred) nettoie le dossier pour éviter le bruit

On peut ajouter des sous-dossiers :

1
shared-context/
2
├── priorities.md
3
├── agent-outputs/
4
│   ├── seo/
5
│   ├── content/
6
│   ├── sales/
7
│   ├── recruiting/
8
│   └── finance/
9
├── feedback/
10
└── kpis/

Toujours des fichiers, toujours des symlinks. Pas de framework.

100 agents

À plus grande échelle, on ajoute :

• Permissions : pas tous les agents need accès à tout (sales lit kpis/ et feedback/, pas content-calendar/)
• Write queues : les agents soumettent à un staging area, le curator valide avant merge (évite le spam)
• Domain namespacing : shared-context/seo/, shared-context/product/ avec synthèse cross-domaine par agent dédié
• Versioning : git-backed shared-context pour historique, rollback, audit

L’architecture ne change pas fondamentalement. C’est toujours “fichiers partagés, lecteurs spécialisés”. On ajoute juste l’organisation comme une entreprise ajoute des départements.

Playbook Progressif (4 semaines)

Semaine 1 : Bâtis 1 agent qui fait quelque chose d’utile. Mets-le sur un cron. Valide que ça marche.

Semaine 2 : Bâtis un 2ème agent dans un domaine différent. Crée shared-context/, symlink-le. Les deux agents écrivent/ligent dans le même dossier.

Semaine 3 : Ajoute la boucle de feedback. Boutons approve/reject. Les deux agents apprennent de tes décisions.

Semaine 4 : Ajoute un agent de synthèse qui lit tous les outputs et trouve les signaux croisés. Tu viens de créer ce qui nous a pris des mois à discover.

En 4 semaines, tu as ce que j’ai mis des mois à comprendre. Un cerveau, plusieurs mains.

Ce Que la Gens Construisent (et C’est Overengineered)

La plupart implémentent :

• Messaging agent-to-agent (API calls)
• Routing layers complexes
• Handoff protocols
• State machines

À 3 agents : c’est du sur-engineering.
À 30 agents : c’est le chaos total.

Ce qui marche vraiment : la meta-physique d’une entreprise. Notion ne fait pas envoyé d’API calls entre marketing et ventes. Ils lisent le même doc. Même principe.

1
WHAT PEOPLE BUILD:            WHAT ACTUALLY WORKS:
2
Agent1 ←→ Agent2              Agent1 ↕️
3
     ↕️    ↕️                       ╲  ↕️
4
↑ Agent3 ←→ Agent4         ┌───┴───┐
5
      ↕️    ↕️               │shared-│
6
Agent5 ←→ Agent6            │context│
7
                            └─┬───┬─┘
8
                                N agents = N² connections   N agents = N connections
9
                                Complex. Fragile. Slow.      Simple. Robust. Fast.

Conclusion

Le multi-agents ne nécessite pas de framework sophistication. Un répertoire partagé, des symlinks, des fichiers Markdown. C’est tout.

La leçon que j’ai apprise : tes agents n’ont pas besoin de “parler” entre eux. Ils ont besoin de lire la même page.

Arrête de construire des silos. Construis un cerveau partagé.

Tags : openclaw, productivite, ia
ReadingTime : 7 min