Cargando la bóveda…
Cargando la bóveda…
Dashboard arriba, Router al medio, agentes especializados con sub-agentes abajo. El patrón para montar un equipo de agentes que se coordinan y avisan cuándo se caen, corriendo en una Mac mini con suscripción mensual de Claude. Sin API key extra.
La primera versión que casi todos montan es la misma: un agente solo con un CLAUDE.md de 600 líneas tratando de hacer email + Shopify + research + atención al cliente.
Funciona 2 días. Después:
El patrón de 3 capas resuelve los 3 síntomas a la vez. No es complejo de montar — solo requiere pensar agentes como equipo, no como individuo.
Un mensaje viaja en una dirección clara: entra por el Router → baja al agente especializado → ese agente coordina sus sub-agentes → la respuesta vuelve por el Router. El Dashboard observa todo desde arriba.
┌─────────────────────┐
│ Dashboard │ ← health check 24/7
│ (observador) │
└──────────┬──────────┘
│ monitorea
┌──────────▼──────────┐
│ Router │ ← entry point (ej: Telegram bot)
│ (recibe, dispatcha)│
└────┬──────┬──────┬──┘
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│Email│ │Shop │ │Comp │ ← agentes especializados
└─┬───┘ └─┬───┘ └─┬───┘
▼ ▼ ▼
sub- sub- sub- ← sub-agentes para trabajo fino
agente agente agenteCada capa tiene un solo trabajo y sabe qué NO hacer — esa es la parte que cuesta respetar.
registry.json compartido)registry.json (compartido entre todos los agentes):
{
"agents": [
{ "name": "email", "path": "/agents/email", "ping_url": "..." },
{ "name": "shopify", "path": "/agents/shopify", "ping_url": "..." },
{ "name": "research", "path": "/agents/research", "ping_url": "..." }
]
}Cada agente actualiza un last_seen.json cada N minutos. El Dashboard lee el registry, hace ping a cada uno, y mantiene un estado global:
{
"checked_at": "2026-05-23T18:42:00Z",
"agents": {
"email": { "status": "ok", "last_ping": "...", "last_error": null },
"shopify": { "status": "slow", "last_ping": "...", "latency_ms": 8400 },
"research": { "status": "down", "last_error": "API rate limited" }
}
}Cuando algo entra en 🔴, manda una notificación (Telegram/email/Slack) a vos, no al usuario.
Dos approaches según volumen:
Approach 1 — Regex / keywords (low volume):
Si el mensaje contiene "pedido", "orden", "tracking" → agente Shopify
Si contiene "factura", "cobrar" → agente Email
Si contiene "competidor", "research" → agente Research
Default → agente GeneralFunciona para casos claros. Falla con frases ambiguas.
Approach 2 — Claude clasificador (high volume):
Un mini-agente cuyo único trabajo es leer el mensaje y devolver un slug del agente destino:
> Mensaje del usuario: "¿llegó la entrega del pedido #2451?"
< { "destination": "shopify", "confidence": 0.95, "context": "tracking query" }Después el Router invoca al agente del slug devuelto.
Patrón común: el Router es un bot de Telegram que vos mandás los mensajes:
Desde tu teléfono operás todo tu negocio.
Cada agente especializado tiene una sola misión clara:
Cada uno tiene su CLAUDE.md específico con su contexto, sus herramientas, sus reglas.
Dentro de cada agente especializado, sub-agentes para tareas más finas:
Email/
├── CLAUDE.md
├── subagents/
│ ├── classifier.md ← clasifica emails entrantes
│ ├── drafter.md ← escribe respuestas
│ └── summarizer.md ← resume threads largosEl agente coordina; los sub-agentes ejecutan piezas.
Hacer agentes "que casi se solapan": uno que hace research general, otro que hace research de competencia. Lo más probable: terminás eligiendo uno y el otro queda muerto.
Regla: dominios separados, no especializaciones del mismo dominio.
El patrón funciona en cualquier máquina con Claude Code que esté siempre prendida. Las opciones realistas:
La mayoría arranca en Mac mini. Una sola, sin display ni mouse — corriendo headless en un rincón.
Sin API key extra. Solo suscripción mensual.
Regla práctica: si tenés ~3 agentes corriendo + sub-agentes, Max 5× alcanza. Más allá, Max 20×.
Si pasaste a usar API key directa, lo gastás en variabilidad — la suscripción mensual te da costo fijo predecible.
Una vez montado, la estructura típica en la Mac mini:
~/ecosystem/
├── registry.json
├── dashboard/
│ ├── CLAUDE.md
│ └── (corre 24/7 monitoreando)
├── router/
│ ├── CLAUDE.md
│ ├── telegram-bridge/
│ └── (corre 24/7 escuchando)
└── agents/
├── email/
│ ├── CLAUDE.md
│ ├── last_seen.json
│ └── subagents/...
├── shopify/
│ ├── CLAUDE.md
│ └── ...
└── research/
├── CLAUDE.md
└── ...Cada agente es una carpeta con su Claude Code propio corriendo. No comparten contexto — comparten archivos versionados (registry, last_seen, logs).
mkdir -p ~/ecosystem/{dashboard,router,agents/email,agents/shopify}
cd ~/ecosystem
echo '{"agents":[]}' > registry.jsonCada carpeta tiene su CLAUDE.md que define:
last_seen.json)En 3 terminales distintas (o tmux):
cd ~/ecosystem/dashboard && claude
cd ~/ecosystem/router && claude
cd ~/ecosystem/agents/email && claudeCada uno con su contexto. Con un launchd / systemd / pm2, los podés tener auto-start al boot.
Mandás un mensaje al bot de Telegram (router):
> Tengo email del cliente Acme?last_seen.jsonSi en algún punto se cae algo, el Dashboard te avisa por separado.
Cae en 2 días. Empezá con un dominio bien acotado (solo email, solo Shopify). Después sumás.
Sin Dashboard, no te enterás cuando algo se cae hasta que el cliente reclama. Tipear el Dashboard antes que los otros agentes parece overkill pero te ahorra dolor.
Si pasás contexto de un agente a otro pegando mensajes, perdés. Usá archivos versionados compartidos (memory palace style).
3 sub-agentes por agente es razonable. 7 sub-agentes es síntoma de que tu agente tiene scope demasiado grande — partilo en dos.
Cada agente que no tenga claro qué NO es su trabajo, va a meterse en lo de otros. La sección "Qué NO hace" en el CLAUDE.md es tan importante como "Qué hace".
Lo que ganás vs un agente monolítico:
El overhead de montaje se paga después del primer mes.