Multi-agent systems con OpenClaw: arquitectura real

TL;DR

• Los sistemas multi-agente no son “varios chatbots hablando”. Son agentes especializados con routing, memoria aislada y skills compartidas.
• OpenClaw implementa routing jerárquico que funciona. Este post detalla la arquitectura, los trade-offs y los problemas reales que encontramos.

¿Qué es un multi-agent system?

Un sistema donde múltiples agentes con roles distintos trabajan juntos para resolver problemas complejos. Cada agente es especialista en un dominio. Un router decide a quién enviar cada request.

La diferencia con un solo agente “todo-en-uno”:

Aspecto	Single agent	Multi-agent
Contexto	Un context window para todo	Contexto aislado por especialidad
Calidad	Jack of all trades, master of none	Especialista por dominio
Coste	Modelo caro para todo	Modelo barato para simple, caro para complejo
Errores	Un error lo rompe todo	Un agente falla, los demás siguen

Arquitectura: Routing jerárquico

El patrón que funciona en producción:

Router (front door — clasifica intención)
├── Researcher (papers, búsqueda, arXiv, web)
├── Coder (desarrollo, debugging, PRs)
├── Writer (contenido, edición, SEO)
├── Analyst (datos, métricas, dashboards)
└── SRE (monitoring, infra, alertas)

El router no es un LLM poderoso. Es un clasificador barato y rápido. Su único trabajo: decidir qué agente debe manejar la request.

Routing con modelo barato:

async def route(message: str) -> str:
    prompt = f"""Clasifica esta mensaje en una categoría:
- research: búsqueda de información, papers, noticias
- code: programación, debugging, revisión de código
- content: escritura, edición, SEO
- data: análisis de datos, métricas
- ops: infraestructura, monitoring

Mensaje: {message}

Responde SOLO con la categoría."""
    
    response = await cheap_model.generate(prompt)
    return response.strip().lower()

Coste del routing: ~$0.0001 por request. Despreciable.

OpenClaw en práctica

OpenClaw implementa esta arquitectura con estos conceptos:

Workspace

Cada agente tiene su workspace aislado:

• Memoria propia: No comparte contexto con otros agentes (por defecto)
• Skills: Herramientas que el agente puede usar
• Config: Modelo, temperatura, max_tokens específicos

Skills compartidas

Las skills son módulos de capacidad que pueden compartirse entre agentes:

skills:
  web-search:
    type: tool
    description: "Buscar en la web"
    mcp: mcp-server-brave-search
  git-operations:
    type: tool
    description: "Operaciones de git"
    mcp: mcp-server-git

Un agente researcher necesita web-search pero no git-operations. Un agente coder necesita git-operations pero no web-search. Las skills se asignan por rol.

Delegación

Cuando un agente necesita ayuda de otro, usa delegación:

# El researcher necesita datos técnicos
result = await delegate(
    agent="analyst",
    task="Extraer métricas de este paper",
    context=paper_text
)

La delegación pasa por el router, que decide si la task necesita un agente diferente.

Cron y proactividad

Los agentes no solo responden. También pueden iniciar acciones:

crons:
  - schedule: "0 8 * * *"
    agent: "researcher"
    task: "Buscar papers nuevos sobre RAG y agentes"
  - schedule: "0 9 * * 1"
    agent: "writer"
    task: "Generar resumen semanal de hallazgos"

Esto convierte el sistema de reactivo a proactivo. Los agentes trabajan en background y te entregan resultados.

Memoria en multi-agent

El problema más difícil: cómo comparten contexto sin sobrecargar.

Enfoque 1: Memoria aislada (recomendado)

Cada agente tiene su propia memoria. No comparte contexto por defecto. Cuando necesitan compartir, usan mensajes estructurados:

{
  "from": "researcher",
  "to": "coder",
  "type": "delegation",
  "summary": "Encontré que el bug está en auth.ts línea 42",
  "evidence": ["paper X dice...", "este test falla porque..."]
}

Enfoque 2: Memoria compartida (peligroso)

Todos los agentes comparten un context window. Problema: se llena rápido, el modelo se confunde con contexto de otros dominios, y un agente puede “contaminar” el contexto de otro.

Solo usar para sistemas simples con 2-3 agentes.

Coste real

Un sistema multi-agent con OpenClaw + routing:

Componente	Modelo	Coste/1K requests
Router	glm-4.5-air (gratis)	$0
Researcher	GPT-4o-mini	$0.15
Coder	Claude Sonnet	$3.00
Writer	GPT-4o-mini	$0.15
Analyst	GPT-4o	$2.50

Coste blended: ~$1-2/día para uso moderado. Mucho menos que un solo agente con Claude Opus para todo.

Problemas que encontramos

1. Routing errors

El router envía la task al agente equivocado. Solución: si el agente receptor detecta que la task no es de su dominio, la devuelve al router con una corrección.

2. Overhead de coordinación

La delegación añade latencia. Cada delegación = 1 LLM call extra. Para tareas que necesitan 3+ delegaciones, la latencia puede ser 15-30s.

3. Debugging difícil

Cuando algo falla, ¿fue el router, el agente, o la skill? Sin logging detallado por paso, es imposible debuguear. OpenClaw genera traces pero necesitas un dashboard para visualizarlos.

4. Coste de modelos caros

El agente coder con Claude Sonnet es caro. Solución: usar modelos baratos para sub-tareas dentro del agente y solo usar el modelo caro para la síntesis final.

Cuándo NO usar multi-agent

• Tareas simples que un solo agente resuelve bien
• Prototipos rápidos (empieza con single-agent)
• Presupuesto muy limitado
• Equipo pequeño sin tiempo para mantener el sistema

Conclusión

Multi-agent systems tienen sentido cuando tienes tareas con dominios distintos, necesitas especialización, y puedes permitirte la complejidad operativa. OpenClaw hace que la implementación sea viable, pero no elimina la complejidad inherent del sistema.

Empieza con un solo agente. Añade agentes cuando tengas evidencia de que lo simple no basta.

---

Fuentes: OpenClaw docs, experiencia propia con sistemas multi-agent en producción.