Un desarrollador en r/openclaw describe su cambio de modelo mental al trabajar con equipos multiagente en OpenClaw. Inicialmente, tratar a los subagentes como empleados junior con nombres, historias de fondo y expectativas de memoria llevó a semanas de confusión y flujos de trabajo rotos.

La Analogía de la Función

El avance llegó al reconocer que los subagentes no son mini-yos o miembros persistentes del equipo—son funciones. Específicamente:

• Los subagentes son llamadas de funciones sin estado, no miembros persistentes del equipo
• Son herramientas especializadas, no versiones junior del desarrollador
• Operan con entrada pura → salida, sin recordar contexto
• Devuelven valores al llamador en lugar de hablar entre ellos

La fuente proporciona ejemplos de código contrastando enfoques erróneos y correctos:

# ERRÓNEO: Tratar al subagente como objeto persistente
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Asume que Frank recuerda

CORRECTO: Tratar al subagente como llamada de función
result = frank_task(
  instructions="Build login page",
  context={"requirements": reqs, "design": mockup}
)
frank_task ejecuta, devuelve salida, termina

Implicaciones Prácticas

Este cambio de modelo mental tiene varias implicaciones concretas:

1. SOUL.md como Docstring de Función: En lugar de perfiles de personalidad, SOUL.md se convierte en un documento de especificación:

# frank_task()
Propósito: Construir características de Next.js
Entradas: requisitos (dict), diseño (opcional)
Salidas: {código, pruebas, notas}
Restricciones: Sin llamadas a API externas sin aprobación

2. Paso Explícito de Estado para Iteración: Dado que los subagentes no recuerdan contexto, debes pasar toda la información necesaria en parámetros:

# ERRÓNEO
frank_fix("fix the bug") # genera, intenta, muere
frank_fix("still broken") # nueva generación, sin contexto

CORRECTO
result = frank_fix({
  "code": previous_output,
  "issues": ["login validation fails", "mobile CSS broken"],
  "test_cases": failing_tests
}) # Contexto completo en parámetros

3. El Coordinador como Programa Principal: El desarrollador se convierte en una función orquestadora en lugar de un gerente de equipo:

def build_feature(spec):

Llama funciones en secuencia
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # Itera con contexto explícito
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

Paralelismos con Diseño de Software

Este enfoque se alinea con principios establecidos de diseño de software:

• Responsabilidad Única: Cada subagente hace una cosa
• Funciones Puras: Misma entrada → misma salida
• Probable por Unidades: Probar la salida de cada subagente independientemente
• Componible: Encadenar subagentes como quinn_test(frank_code(spec))
• Sin Estado: Sin dependencias ocultas

El desarrollador señala que el valor no es "más agentes = más inteligencia" sino "funciones especializadas = arquitectura más limpia".

Resultados Después del Cambio

Después de adoptar este modelo, el desarrollador construyó:

• Una base de datos de 11,249 gimnasios en 2 semanas
• 5 agentes especializados (no 5 generalistas)
• Un CRM con flujos de trabajo de suscripción
• Compromiso diario con Moltbook

Todo usando subagentes sin estado y un coordinador que mantiene el contexto.