Un développeur sur r/openclaw décrit le changement de son modèle mental lorsqu'il travaille avec des équipes multi-agents dans OpenClaw. Traiter initialement les sous-agents comme des employés juniors avec des noms, des histoires personnelles et des attentes de mémoire a conduit à des semaines de confusion et de flux de travail rompus.

L'analogie de la fonction

La percée est venue de la reconnaissance que les sous-agents ne sont pas des mini-moi ou des membres d'équipe persistants—ce sont des fonctions. Plus précisément :

• Les sous-agents sont des appels de fonction sans état, pas des membres d'équipe persistants
• Ce sont des outils spécialisés, pas des versions juniors du développeur
• Ils fonctionnent sur le principe entrée → sortie pure, sans mémoriser le contexte
• Ils renvoient des valeurs à l'appelant plutôt que de communiquer entre eux

La source fournit des exemples de code contrastant les mauvaises et bonnes approches :

# MAUVAIS : Traiter le sous-agent comme un objet persistant
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Suppose que Frank se souvient

BON : Traiter le sous-agent comme un appel de fonction
result = frank_task(
  instructions="Construire la page de connexion",
  context={"requirements": reqs, "design": mockup}
)
frank_task s'exécute, renvoie une sortie, se termine

Implications pratiques

Ce changement de modèle mental a plusieurs implications concrètes :

1. SOUL.md comme docstring de fonction : Au lieu de profils de personnalité, SOUL.md devient un document de spécification :

# frank_task()
Objectif : Construire des fonctionnalités Next.js
Entrées : exigences (dict), design (optionnel)
Sorties : {code, tests, notes}
Contraintes : Pas d'appels API externes sans approbation

2. Passage d'état explicite pour l'itération : Puisque les sous-agents ne mémorisent pas le contexte, vous devez transmettre toutes les informations nécessaires dans les paramètres :

# MAUVAIS
frank_fix("corriger le bug") # naît, essaie, meurt
frank_fix("toujours cassé") # nouvelle naissance, pas de contexte

BON
result = frank_fix({
  "code": previous_output,
  "issues": ["la validation de connexion échoue", "CSS mobile cassé"],
  "test_cases": failing_tests
}) # Contexte complet dans les paramètres

3. Le coordinateur comme programme principal : Le développeur devient une fonction d'orchestration plutôt qu'un manager d'équipe :

def build_feature(spec):

Appeler les fonctions en séquence
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # Itérer avec un contexte explicite
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

Parallèles avec la conception logicielle

Cette approche s'aligne avec les principes établis de conception logicielle :

• Responsabilité unique : Chaque sous-agent fait une seule chose
• Fonctions pures : Même entrée → même sortie
• Testabilité unitaire : Tester la sortie de chaque sous-agent indépendamment
• Composabilité : Enchaîner les sous-agents comme quinn_test(frank_code(spec))
• Sans état : Pas de dépendances cachées

Le développeur note que la valeur n'est pas "plus d'agents = plus d'intelligence" mais "fonctions spécialisées = architecture plus propre".

Résultats après le changement

Après avoir adopté ce modèle, le développeur a construit :

• Une base de données de 11 249 salles de sport en 2 semaines
• 5 agents spécialisés (pas 5 généralistes)
• Un CRM avec des flux de travail de souscription
• Un engagement quotidien sur Moltbook

Tout cela en utilisant des sous-agents sans état et un coordinateur qui maintient le contexte.