Tengo 20 agentes de IA trabajando para mi negocio. No es un título clickbait — es mi sistema real, y funciona desde hace 2 meses.

Manejan mi contenido, mi SEO, mi CRM, mis automatizaciones, mis videos, mis analytics. Cada uno tiene un rol específico, reglas claras de comunicación, y acceso a herramientas reales via MCPs.

En este artículo te voy a mostrar exactamente cómo lo diseñé, qué patterns funcionan, qué errores cometí, y qué resultados estoy viendo. Todo corre en Claude Code CLI — no es una plataforma externa, no es un framework experimental, no es teoría.

Si estás pensando en armar algo similar para tu negocio o proyecto, esto te va a ahorrar semanas de prueba y error.

Por qué un solo Claude no alcanza

Cuando empecé a usar Claude Code para mi consultoría, el flujo era simple: una sesión, un contexto, y yo dirigiendo todo manualmente. Funcionaba para tareas puntuales — escribir un componente, corregir un bug, generar un artículo.

El problema apareció cuando el negocio creció. Necesitaba que Claude manejara SEO, CRM, contenido para LinkedIn, automatizaciones en n8n, deploys, analytics, y desarrollo web. Todo al mismo tiempo, todo con contexto diferente.

Un solo Claude tiene límites prácticos:

Contexto finito. Aunque Opus 4.6 tiene 1M tokens de contexto, si le cargás la documentación de SEO + las reglas de copywriting + la configuración del CRM + el codebase del sitio web, el rendimiento se degrada. No por capacidad, sino por dilución de atención.
Sin especialización. Un Claude generalista produce resultados "buenos" en todo pero "excelentes" en nada. Un agente que solo hace SEO, con las skills de SEO cargadas y acceso a Google Search Console, produce resultados significativamente mejores que un Claude que intenta hacer SEO entre medio de otras 15 tareas.
Sin memoria entre tareas. Si le pedís que escriba un artículo de blog y después que audite el SEO, pierde el contexto de la primera tarea. No hay continuidad natural.
Cuello de botella: vos. Si vos sos el que tiene que descomponer cada tarea, asignarla, y verificar el resultado, no estás escalando — estás micromanaging a una IA.

La solución no es usar más Claude. Es organizar múltiples Claudes con roles, reglas y herramientas específicas.

La arquitectura: 8 áreas de negocio

Mi sistema está organizado como un equipo real de empresa. No porque quiera jugar a ser corporativo, sino porque esa estructura resuelve problemas concretos de coordinación.

                    ORQUESTADOR (Opus, delegate-first)
                              |
    +-----------+-----------+-----------+-----------+
    |           |           |           |           |
 PRODUCTO   CONTENIDO  CRECIMIENTO   OPS     INTELIGENCIA
    |           |           |           |
 frontend   copywriter  seo-spec   ghl-spec
 backend    linkedin    cro-anal   auto-builder
 video      email-mkt

    +-----------+-----------+
    |           |           |
  VENTAS    FINANZAS      LEGAL        + IMPROVER (transversal)

Las 8 áreas y por qué existen

1. Producto (product-lead + 3 sub-agentes) Desarrollo web, videos con Remotion, y QA. El jefe coordina a frontend-dev, backend-dev y video-creator. Cuando necesito una feature nueva en el sitio web, no le pido a Claude genérico — el product-lead analiza el pedido, decide si es frontend o backend, y delega al sub-agente correcto con las skills de Next.js, React 19 y Tailwind v4 ya cargadas.

2. Contenido (content-lead + 3 sub-agentes) Copy, blog, LinkedIn, emails. Tiene a copywriter (artículos y copy general), linkedin-content (posts optimizados para LinkedIn), y email-marketer (secuencias de email). El content-lead lee un archivo llamado content-log.md que registra todo lo que ya se publicó — así evita repetir temas.

3. Crecimiento (growth-lead + 2 sub-agentes) SEO, CRO, analytics. El seo-specialist tiene acceso directo a Google Search Console via MCP y maneja 13 skills de SEO. El cro-analytics trabaja con Google Analytics GA4. El jefe consolida reportes y prioriza acciones.

4. Operaciones (ops-lead + 2 sub-agentes) CRM y automatizaciones. El ghl-specialist maneja Go High Level (36 tools via MCP) — contactos, pipeline, calendario, emails. El automation-builder diseña workflows en n8n (16 tools via MCP). Cuando un lead llega por el formulario web, Operaciones se encarga de que el workflow completo funcione.

5. Inteligencia (intel-lead, sin sub-agentes) Investigación y tendencias. Busca novedades de IA, analiza competencia, y alimenta a las otras áreas con información fresca. Tiene un pipeline de 15 canales de YouTube que monitorea y genera daily briefs.

6. Ventas (sales-lead, sin sub-agentes) Pipeline, outreach, propuestas, cálculos de ROI. Trabaja directamente con Go High Level para gestionar oportunidades.

7. Finanzas (finance-lead, sin sub-agentes) Facturación, gastos, vencimientos. Todavía es el área menos desarrollada, pero ya maneja el tracking de costos operativos.

8. Legal (legal-lead, sin sub-agentes) Contratos, términos y condiciones, GDPR, acuerdos de confidencialidad.

Transversal: Improver Un agente que no pertenece a ningún área. Su trabajo es revisar cómo funcionan los otros agentes, detectar ineficiencias, y proponer mejoras. Es como un auditor interno que corre periódicamente.

El patrón jefe-subordinado

No todos los agentes son iguales. La diferencia de roles es intencional y tiene un impacto directo en costos y calidad.

Por qué Opus como jefe y Sonnet como ejecutor

Los jefes de área corren en Opus 4.6. Los sub-agentes ejecutores corren en Sonnet 4.6.

La lógica es simple:

Opus es mejor para planificar, descomponer y decidir. Cuando el content-lead recibe "escribí un artículo de blog sobre MCPs", necesita decidir: qué ángulo tomar, qué keywords apuntar, qué artículos internos linkar, si ya se cubrió ese tema antes. Eso requiere razonamiento complejo.
Sonnet es mejor para ejecutar tareas bien definidas. Cuando el copywriter recibe "escribí un artículo MDX con este título, estas keywords, este ángulo, y linkea a estos 3 artículos", la tarea es clara. Sonnet lo hace igual de bien que Opus, a una fracción del costo.
El ahorro es real. Opus cuesta $5/$25 por millón de tokens (input/output). Sonnet cuesta $3/$15. Si el 70% de las tareas las ejecutan sub-agentes Sonnet, el costo operativo baja dramáticamente.

Ejemplo real: cómo content-lead delega a copywriter

Cuando le pido al sistema "escribí un artículo de blog sobre herramientas de IA gratis", esto es lo que pasa:

El orquestador identifica que es una tarea de contenido y delega a content-lead.
El content-lead (Opus) lee content-log.md para verificar que no se haya escrito algo similar. Lee product-marketing-context.md para recordar el tono de voz y el público objetivo. Decide el ángulo, las keywords, y la estructura.
El content-lead crea un brief y lo pasa al copywriter (Sonnet) con instrucciones específicas: título, estructura de secciones, keywords a incluir, artículos internos a linkar, largo objetivo.
El copywriter ejecuta: genera el archivo MDX completo con frontmatter, schema markup, y contenido optimizado para SEO.
El content-lead revisa el resultado, ajusta si es necesario, y reporta que está listo.

La clave es que el jefe nunca escribe el artículo. Planifica, decide, y revisa. El sub-agente ejecuta.

Cuándo NO necesitás sub-agentes

No todas las áreas necesitan subordinados. Inteligencia, Ventas, Finanzas y Legal funcionan con un solo agente cada una. La regla es simple: si el volumen y la variedad de tareas de un área justifican especialización, creás sub-agentes. Si no, un solo agente alcanza.

Inteligencia, por ejemplo, hace investigación y genera briefs. Es una tarea relativamente uniforme. No necesita un sub-agente para "buscar en YouTube" y otro para "buscar en la web" — el mismo intel-lead hace todo.

Las 3 reglas que evitan el caos

Un sistema multi-agente sin reglas claras es peor que no tener sistema. Aprendí esto por las malas. Estas son las 3 reglas que mantienen todo funcionando:

1. No-callback rule

Si el Área A llama al Área B, B no puede llamar de vuelta a A.

Esto suena obvio pero es fundamental. Sin esta regla, terminás con loops infinitos. Imaginate: Contenido le pide a Crecimiento que haga keyword research. Crecimiento encuentra que falta contenido sobre un tema y le pide a Contenido que lo escriba. Contenido le pide a Crecimiento que valide las keywords del nuevo artículo. Y así hasta el infinito.

Con la no-callback rule, el flujo es lineal. Contenido pide keyword research a Crecimiento. Crecimiento responde con los datos. Fin de la interacción. Si Crecimiento detecta una oportunidad de contenido, la deja documentada en un handoff para que Contenido la recoja en su próximo ciclo — pero no la ejecuta ni la delega de vuelta.

2. Max depth 3

Las cadenas de delegación no superan 3 niveles.

Nivel 1: Orquestador → content-lead
Nivel 2: content-lead → copywriter
Nivel 3: copywriter ejecuta

Nunca hay un nivel 4. Si una tarea requiere más de 3 niveles de profundidad, es una señal de que la tarea está mal descompuesta. Hay que rediseñarla, no agregar más capas.

En la práctica, la mayoría de las tareas operan en 2 niveles (orquestador a jefe, jefe ejecuta) o 3 niveles (orquestador a jefe, jefe a sub-agente, sub-agente ejecuta).

3. Delegate-first

El orquestador NUNCA implementa. Solo analiza, descompone, delega y consolida.

Esta es la regla más difícil de respetar porque es tentador que el orquestador "ayude" con tareas simples. Pero si rompés esta regla una vez, perdés la estructura.

El orquestador recibe un pedido, decide qué área (o áreas) lo manejan, y delega. Si el resultado necesita ajustes, se lo devuelve al área — no lo arregla él.

La excepción: tareas triviales (corregir un typo, cambiar un color) van directo a Claude sin pasar por el sistema de agentes. No tiene sentido activar toda la maquinaria para un cambio de 2 segundos.

MCPs: el sistema nervioso

Los agentes sin herramientas son solo texto generando texto. Lo que hace que mi sistema sea funcional en la práctica son los MCPs — Model Context Protocol.

Si no sabés qué es MCP, tengo una guía completa. En resumen: MCP es un estándar abierto que permite que Claude se conecte a herramientas externas. No es una API custom ni un plugin — es un protocolo estandarizado con un ecosistema creciente de servidores.

Mi sistema tiene 12 MCPs conectados:

MCP	Tools	Quién lo usa	Para qué
Go High Level	36	ops-lead, sales-lead	CRM: contactos, pipeline, calendario, emails, pagos
Google Search Console	15+	growth-lead, seo-specialist	SEO: queries, indexación, sitemaps, Core Web Vitals
Google Analytics GA4	10+	growth-lead, cro-analytics	Tráfico, eventos, conversiones, audiencias
Meta (IG/Threads)	57	content-lead	Publicar en Instagram y Threads, insights, DMs
GitHub	20	product-lead	Repos, issues, PRs, code search
n8n	16	ops-lead, automation-builder	Workflows: crear, validar, testear, templates
Vercel	18	product-lead	Deploy, logs, dominios
Playwright	20	product-lead, intel-lead	Browser automation, E2E testing, screenshots
Context7	2	product-lead	Documentación actualizada de cualquier librería
Engram	11	Todos	Memoria persistente entre sesiones
Excalidraw	8	product-lead	Diagramas programáticos
Sequential Thinking	1	Todos	Razonamiento paso a paso para problemas complejos

Ejemplo concreto: cómo fluyen las herramientas

Cuando le pido al sistema "hacé una auditoría SEO completa", esto pasa:

El orquestador delega a growth-lead.
growth-lead activa al seo-specialist.
seo-specialist usa Google Search Console MCP para: consultar queries top, verificar páginas indexadas, revisar sitemaps, inspeccionar URLs problemáticas, chequear Core Web Vitals.
En paralelo, cro-analytics usa Google Analytics GA4 MCP para: pull de tráfico por fuente, páginas más visitadas, tasas de rebote, conversiones.
growth-lead consolida ambos reportes, cruza datos (ej: "esta página tiene buen tráfico pero mala posición en GSC — oportunidad de optimización"), y genera un reporte con score y prioridades.

Sin MCPs, ese proceso sería: yo copio datos de Search Console, los pego en Claude, espero respuesta, voy a Analytics, copio más datos, pego, espero. Con MCPs, los agentes acceden directamente a las herramientas y hacen todo en una sola sesión.

El archivo CLAUDE.md como cerebro

Si tuviera que elegir una sola cosa que hace que este sistema funcione, es el archivo CLAUDE.md.

Claude Code lee automáticamente los archivos CLAUDE.md del directorio donde se ejecuta. Esto significa que podés documentar todo lo que un agente necesita saber, y Claude lo va a tener como contexto desde el momento cero.

Mi CLAUDE.md principal tiene 400+ líneas. Incluye:

Identificadores del proyecto — dominio, directorios, repos, branch, deploy
Tech stack completo — frameworks, versiones, configuración específica
Estructura del proyecto — qué hay en cada carpeta
Arquitectura de agentes — las 8 áreas, quién es quién, cómo se comunican
MCPs disponibles — qué herramientas tiene cada agente
Skills por área — qué habilidades están cargadas para cada rol
Reglas del proyecto — las restricciones que NUNCA se rompen
Estado actual — qué está hecho, qué está pendiente
Variables de entorno — qué secrets existen y para qué
Servicios externos — qué está conectado, en qué estado

Por qué es tan importante

Sin CLAUDE.md, cada sesión de Claude empieza de cero. Le tenés que explicar el stack, las convenciones, las restricciones, el contexto del negocio. Cada vez.

Con CLAUDE.md, Claude arranca sabiendo todo. Sabe que el sitio usa Next.js 16 con App Router, que los colores son emerald y gold, que el deploy va a Vercel con root en website/, que los formularios pasan por Go High Level, que el SEO lo maneja growth-lead con acceso a GSC.

Tip concreto: Cada agente tiene acceso a CLAUDE.md pero también puede tener su propio archivo de instrucciones en .claude/agents/[nombre].md. Ahí van las instrucciones específicas de ese rol — qué skills usar, qué archivos leer primero, qué formato de output producir.

El CLAUDE.md es el conocimiento global. Los archivos de agente son el conocimiento específico del rol. Juntos, le dan a cada agente el contexto exacto que necesita sin ruido innecesario.

Comunicación entre áreas

En un equipo humano, la comunicación fluye naturalmente — mandás un Slack, hacés una reunión, dejás un comentario en Notion. Con agentes de IA, tenés que diseñar la comunicación explícitamente.

Handoffs

El mecanismo principal de comunicación entre áreas son los handoffs. Son archivos markdown en .claude/shared/handoffs/ con el formato [origen]-[destino].md.

Por ejemplo, intel-content.md es donde Inteligencia le deja información a Contenido. Puede ser un tema trending que detectó, un artículo de la competencia que vale la pena cubrir, o datos de investigación que sirven para un blog post.

.claude/shared/handoffs/
├── intel-content.md      # Inteligencia → Contenido
├── intel-growth.md       # Inteligencia → Crecimiento
├── intel-sales.md        # Inteligencia → Ventas
├── growth-product.md     # Crecimiento → Producto
└── content-growth.md     # Contenido → Crecimiento

La ventaja de usar archivos planos es que son trazables. Puedo abrir un handoff y ver exactamente qué información pasó de un área a otra, cuándo, y por qué.

Decisiones compartidas

Las decisiones que afectan a múltiples áreas se documentan en .claude/shared/decisions.md. Formato simple: fecha, decisión, áreas involucradas, razón.

Esto evita el problema clásico de "eso ya se decidió pero nadie se enteró". Si growth-lead decide cambiar la estrategia de keywords, queda registrado para que content-lead lo vea en su próximo ciclo.

Cómo evitar duplicación

El anti-patrón más común en sistemas multi-agente es que dos agentes hagan la misma tarea sin saberlo. Mi solución tiene dos partes:

content-log.md: Registro de todo el contenido creado. Antes de escribir algo, content-lead lo revisa. Si ya existe un artículo sobre el tema, no lo duplica — puede actualizarlo o buscar un ángulo diferente.
Áreas bien definidas: Si algo es SEO, lo hace growth-lead. Si algo es copy, lo hace content-lead. No hay overlap intencional. Cuando una tarea cae en zona gris (ej: "optimizar el copy de una landing para SEO"), el orquestador asigna un área principal y la otra actúa como consultora via handoff.

Errores que cometí (y cómo los corregí)

Error 1: Empezar con demasiados agentes

Mi primer diseño tenía 20 agentes desde el día uno. Fue un error. Tenía agentes que no usaba, configuraciones que no probé, y complejidad que no necesitaba.

Lo que funcionó: Empezar con 3-4 agentes (producto, contenido, y crecimiento) y ir agregando a medida que la necesidad real aparecía. Operaciones surgió cuando el CRM se volvió complejo. Inteligencia surgió cuando necesité monitorear tendencias sistemáticamente. Ventas surgió cuando el pipeline creció.

Regla práctica: Si no le asignás tareas a un agente al menos una vez por semana, probablemente no lo necesitás todavía.

Error 2: No documentar las reglas de comunicación desde el principio

Al principio no tenía handoffs ni reglas de no-callback. Los agentes se mandaban entre sí de forma caótica. Un agente de contenido le pedía datos a crecimiento, crecimiento le pedía a inteligencia que investigara algo, inteligencia generaba un brief que iba a contenido, contenido le pedía a crecimiento que validara... circular.

Lo que funcionó: Definir las 3 reglas (no-callback, max depth 3, delegate-first) y crear la estructura de handoffs ANTES de seguir escalando. Fue un refactor doloroso pero necesario. Después de implementar las reglas, la comunicación se volvió predecible y trazable.

Error 3: Subestimar la importancia del CLAUDE.md

Mi primer CLAUDE.md tenía 30 líneas. Stack, directorio, y poco más. El resultado era que cada agente tomaba decisiones inconsistentes — uno usaba colores diferentes, otro generaba código con convenciones distintas, otro no sabía que el deploy iba a Vercel.

Lo que funcionó: Invertir un día completo en documentar TODO en el CLAUDE.md. Las 400+ líneas actuales no son burocracia — cada línea existe porque en algún momento un agente hizo algo incorrecto por falta de contexto. El CLAUDE.md es un documento vivo que crece con el proyecto.

Error 4: No usar Engram para memoria entre sesiones

Claude Code pierde contexto cuando cerrás la sesión. Al principio, cada nueva sesión arrancaba de cero y tenía que re-explicar decisiones anteriores.

Lo que funcionó: Conectar Engram (MCP de memoria persistente) y entrenar el hábito de guardar decisiones importantes, bugs encontrados, y contexto de arquitectura. Ahora cuando arranco una sesión nueva, los agentes pueden buscar en la memoria y recuperar contexto de sesiones anteriores.

Resultados concretos

Después de 2 meses con el sistema funcionando, estos son los cambios tangibles:

Velocidad de producción de contenido. Antes escribía 1-2 artículos de blog por semana con esfuerzo. Ahora produzco 6-9 artículos por semana con calidad consistente. El sistema maneja SEO, internal linking, schema markup, y formato MDX sin intervención manual.

SEO systemático. Antes, el SEO era reactivo — "a ver cómo están las keywords". Ahora, growth-lead corre auditorías periódicas con acceso directo a Search Console y GA4. Detecta oportunidades automáticamente y genera handoffs para que contenido los cubra.

CRM automatizado. El flujo de leads está 100% automatizado: formulario web a Go High Level a pipeline a secuencia de emails a booking. ops-lead monitorea que todo funcione y automation-builder mantiene los workflows de n8n.

Capacidad multitarea real. Puedo pedirle al sistema que simultáneamente: audite el SEO, genere un artículo de blog, verifique el estado del pipeline de ventas, y revise los analytics de la semana. Cada tarea va al área correcta y se ejecuta sin conflictos.

Documentación viva. El CLAUDE.md, los handoffs, las decisiones compartidas, el content log — todo se mantiene actualizado como subproducto del trabajo de los agentes. No es documentación extra que tengo que hacer manualmente.

Lo que NO cambió: Sigo siendo yo quien decide la estrategia, aprueba contenido importante, y habla con clientes. El sistema no reemplaza el juicio humano — lo amplifica.

Cómo empezar si querés armar algo similar

No necesitás 20 agentes ni 12 MCPs desde el día uno. Empezá con esto:

Paso 1: Escribí un CLAUDE.md sólido. Documentá tu stack, tus convenciones, tu estructura de proyecto, y las reglas que no se rompen. Esto solo ya mejora dramáticamente la calidad de las respuestas de Claude.

Paso 2: Identificá 2-3 áreas donde más necesitás ayuda. Para la mayoría de los negocios, esas áreas son contenido, desarrollo, y operaciones.

Paso 3: Creá un agente por área con instrucciones específicas en archivos .md. Probalo durante una semana. Ajustá las instrucciones basándote en lo que funciona y lo que no.

Paso 4: Conectá MCPs para las herramientas que ya usás. Si usás Google Search Console, conectá el MCP de GSC. Si usás un CRM, conectá su MCP. Cada MCP que conectás multiplica la utilidad de tus agentes.

Paso 5: Definí reglas de comunicación entre áreas ANTES de que las necesites. No-callback, max depth 3, delegate-first. Te van a parecer innecesarias con 2-3 agentes, pero cuando escales a 10+ te van a salvar.

Conclusión

Un sistema de 20 agentes suena complejo, y lo es. Pero la complejidad no está en la tecnología — Claude Code, los MCPs, y los archivos markdown son herramientas simples. La complejidad está en el diseño organizacional: qué agentes necesitás, cómo se comunican, qué reglas los mantienen en orden.

Si documentás bien (CLAUDE.md), definís roles claros (jefe-subordinado), establecés reglas de comunicación (no-callback, max depth, delegate-first), y conectás herramientas reales (MCPs), tenés un sistema que escala sin romperse.

No es perfecto. Todavía ajusto cosas cada semana. Pero la diferencia entre "yo haciendo todo manualmente" y "un sistema de 20 agentes ejecutando en paralelo" es la diferencia entre un freelancer y un equipo.

Si querés diseñar un sistema de agentes para tu proyecto, agendá una llamada y lo armamos juntos.

Cómo Construí un Sistema de 20 Agentes con Claude Code (Arquitectura Real)