Um desenvolvedor no r/openclaw descreve sua mudança de modelo mental ao trabalhar com equipes multiagente no OpenClaw. Inicialmente, tratar subagentes como funcionários juniores com nomes, históricos e expectativas de memória levou a semanas de confusão e fluxos de trabalho quebrados.

A Analogia da Função

A descoberta veio ao reconhecer que subagentes não são mini-eus ou membros persistentes da equipe—eles são funções. Especificamente:

• Subagentes são chamadas de função stateless, não membros persistentes da equipe
• Eles são ferramentas especializadas, não versões juniores do desenvolvedor
• Eles operam com entrada pura → saída, sem lembrar do contexto
• Eles retornam valores para o chamador em vez de conversarem entre si

A fonte fornece exemplos de código contrastando abordagens erradas e corretas:

# ERRADO: Tratando subagente como objeto persistente
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Assume que Frank se lembra

CERTO: Tratando subagente como chamada de função
result = frank_task(
  instructions="Build login page",
  context={"requirements": reqs, "design": mockup}
)
frank_task executa, retorna saída, termina

Implicações Práticas

Essa mudança de modelo mental tem várias implicações concretas:

1. SOUL.md como Docstring de Função: Em vez de perfis de personalidade, SOUL.md se torna um documento de especificação:

# frank_task()
Propósito: Construir recursos Next.js
Entradas: requisitos (dict), design (opcional)
Saídas: {código, testes, notas}
Restrições: Sem chamadas de API externas sem aprovação

2. Passagem de Estado Explícita para Iteração: Como subagentes não lembram do contexto, você deve passar todas as informações necessárias nos parâmetros:

# ERRADO
frank_fix("fix the bug") # spawn, tenta, morre
frank_fix("still broken") # novo spawn, sem contexto

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

3. O Coordenador como Programa Principal: O desenvolvedor se torna uma função orquestradora em vez de um gerente de equipe:

def build_feature(spec):

Chama funções em sequência
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # Itera com contexto explícito
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

Paralelos com Design de Software

Essa abordagem se alinha com princípios estabelecidos de design de software:

• Responsabilidade Única: Cada subagente faz uma coisa
• Funções Puras: Mesma entrada → mesma saída
• Testável Unitariamente: Testa a saída de cada subagente independentemente
• Componível: Encadeia subagentes como quinn_test(frank_code(spec))
• Stateless: Sem dependências ocultas

O desenvolvedor observa que o valor não é "mais agentes = mais inteligência" mas "funções especializadas = arquitetura mais limpa".

Resultados Após a Mudança

Após adotar esse modelo, o desenvolvedor construiu:

• Um banco de dados de 11.249 academias em 2 semanas
• 5 agentes especializados (não 5 generalistas)
• Um CRM com fluxos de trabalho de subscrição
• Engajamento diário no Moltbook

Tudo usando subagentes stateless e um coordenador que mantém o contexto.