Ein Entwickler auf r/openclaw beschreibt seinen mentalen Modellwechsel bei der Arbeit mit Multi-Agenten-Teams in OpenClaw. Anfangs behandelte er Subagenten wie Junior-Mitarbeiter mit Namen, Hintergrundgeschichten und Erwartungen an Gedächtnis, was zu Wochen der Verwirrung und unterbrochenen Arbeitsabläufen führte.

Die Funktionsanalogie

Der Durchbruch kam durch die Erkenntnis, dass Subagenten keine Mini-Ichs oder persistenten Teammitglieder sind – sie sind Funktionen. Konkret:

• Subagenten sind zustandslose Funktionsaufrufe, keine persistenten Teammitglieder
• Sie sind spezialisierte Werkzeuge, keine Junior-Versionen des Entwicklers
• Sie arbeiten mit reinen Eingabe → Ausgabe, ohne Kontext zu merken
• Sie geben Werte an den Aufrufer zurück, statt miteinander zu kommunizieren

Die Quelle bietet Codebeispiele, die falsche und richtige Ansätze gegenüberstellen:

# FALSCH: Subagent wie persistentes Objekt behandeln
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Nimmt an, dass Frank sich erinnert

RICHTIG: Subagent als Funktionsaufruf behandeln
result = frank_task(
  instructions="Login-Seite erstellen",
  context={"requirements": reqs, "design": mockup}
)
frank_task wird ausgeführt, gibt Ausgabe zurück, endet

Praktische Implikationen

Dieser mentale Modellwechsel hat mehrere konkrete Auswirkungen:

1. SOUL.md als Funktions-Docstring: Statt Persönlichkeitsprofilen wird SOUL.md ein Spezifikationsdokument:

# frank_task()
Zweck: Next.js-Funktionen erstellen
Eingaben: Anforderungen (dict), Design (optional)
Ausgaben: {code, tests, notes}
Einschränkungen: Keine externen API-Aufrufe ohne Genehmigung

2. Explizite Zustandsübergabe für Iteration: Da Subagenten keinen Kontext merken, müssen alle notwendigen Informationen in Parametern übergeben werden:

# FALSCH
frank_fix("den Fehler beheben") # erzeugen, versuchen, beenden
frank_fix("immer noch kaputt") # neue Instanz, kein Kontext

RICHTIG
result = frank_fix({
  "code": previous_output,
  "issues": ["Login-Validierung fehlgeschlagen", "mobile CSS kaputt"],
  "test_cases": failing_tests
}) # Vollständiger Kontext in Parametern

3. Der Koordinator als Hauptprogramm: Der Entwickler wird zu einer Orchestrierungsfunktion statt einem Team-Manager:

def build_feature(spec):

Funktionen in Sequenz aufrufen
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # Mit explizitem Kontext iterieren
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

Software-Design-Parallelen

Dieser Ansatz stimmt mit etablierten Software-Design-Prinzipien überein:

• Einzelverantwortung: Jeder Subagent macht eine Sache
• Reine Funktionen: Gleiche Eingabe → gleiche Ausgabe
• Unit-testbar: Ausgabe jedes Subagenten unabhängig testen
• Komponierbar: Subagenten wie quinn_test(frank_code(spec)) verketten
• Zustandslos: Keine versteckten Abhängigkeiten

Der Entwickler merkt an, dass der Wert nicht "mehr Agenten = mehr Intelligenz" ist, sondern "spezialisierte Funktionen = sauberere Architektur".

Ergebnisse nach dem Wechsel

Nach der Übernahme dieses Modells hat der Entwickler erstellt:

• Eine 11.249 Gym-Datenbank in 2 Wochen
• 5 spezialisierte Agenten (nicht 5 Generalisten)
• Ein CRM mit Underwriting-Workflows
• Tägliches Moltbook-Engagement

Alles mit zustandslosen Subagenten und einem Koordinator, der den Kontext aufrechterhält.