Outbound multi-agente: Claude Code/Cowork + el pegamento que nadie documenta

Respuesta directa

Ya jugaste con un chat que “hace outbound”. Genera emails. Bonitos. Y se rompe en el handoff: el CRM no se entera, el sequencer traga basura, nadie revisa. Esta pieza mapea outbound multi-agente como sistema: roles, contrato JSON/YAML mínimo, y un piloto de 5 cuentas donde documentas dónde se rompe el pegamento — el que nadie pone en el tutorial del vendor. La tesis es operativa: la ventaja no es más prompts: es orquestación con handoffs y gate humano. Anthropic documenta multiagent orchestration (coordinador + agentes especializados en paralelo, contexto aislado) en su plataforma de agentes (Anthropic Docs — Multiagent orchestration) y casos GTM donde skills de contexto de cuenta + drafts pasan por revisión humana, empaquetados incluso como plugin en Cowork (Anthropic GTM / Claude Code). Úsalo como arquitectura de categoría, no como “hazlo exactamente así en producción mañana” ni como partnership de HelloMrLead. El patrón se alinea con Issues 1–3: research usable, lista viva, secuencia corta. El Issue 4 solo une las piezas. Claude Code / Cowork aparecen aquí como ejemplos de categoría de orquestador local — no como stack oficial HML ni garantía de pipeline.

Un agente ≠ un sistema outbound

Un chat único mezcla contextos, no deja contrato auditable y empuja a enviar sin gates. Un sistema tiene pasos con inputs/outputs tipados y un dueño humano del send. El síntoma del “falso sistema”: copy bonita + CRM vacío + dominio en riesgo.

Qué problema resuelve la orquestación

• Especialización: research ≠ copy ≠ validación email.
• Paralelización: varias cuentas a la vez sin contaminar contexto (Anthropic insiste en contexto aislado por agente/hilo).
• Blast radius: un fallo no pudre todo el lote.
• Observabilidad: sabes en qué paso murió el lead.

Para el marco de IA generativa aplicada con cabeza: inteligencia artificial generativa en marketing. Para el mapa de tools sin culto al logo: herramientas de automatización de ventas.

Cómo repartir el trabajo en un equipo de 1–3 personas

Si sois uno: llevas Sender + review; el agente hace Researcher/Copywriter draft; Enricher puede ser validador + tú archivas. Si sois dos: RevOps dueño Enricher + contrato; SDR/founder Sender. Si sois tres: añade un dueño del brief de research (versionado). El organigrama importa menos que la regla: nadie envía sin human_approval. No hace falta contratar “Head of Agents”. Hace falta una hoja con nombres al lado de cada rol y una cola visible de pending approval. Sin dueño, el handoff muere en Slack.

Los 4 roles mínimos (dibuja esto)

Rol	Hace	No hace	Ejemplo categoría tool
Researcher	5 señales + hipótesis	Enviar emails	Claude / agente + web fetch
Enricher	verified_at, email/empresa	Inventar dolor	Validador email + CRM
Copywriter (draft)	Draft 3–4 pasos con slots	Autorizar envío	LLM con plantilla fija
Sender humano	Aprueba / edita / envía / responde	Dejar “send all” ciego	Instantly/HeyReach UI

Variantes sanas

• Founder técnico hace Sender + review de copy.
• SDR es Sender; RevOps dueño Enricher.
• Un coordinador (Cowork/Claude Code categoría) despacha a sub-agentes — pero Sender sigue humano.

Anti-patrón

Un solo agente “full outbound” con permiso de envío autónomo el día 1. Eso no es productividad: es blast radius con API key. El rol humano del Sender encaja con cómo defines el SDR en tu estrategia B2B y con qué es un SDR: el agente drafted; el SDR (o founder) decide y responde.

Contrato de datos entre pasos (el pegamento)

Sin contrato no hay orquestación: hay copy-paste. Cada agente lee solo los campos que necesita. usable=false corta el flujo antes de Copywriter. verification_status=fail (2×) → archive (Issue 2). human_approval obligatorio antes de send_status=sent.

Esquema mínimo sugerido (YAML/JSON conceptual)

account_id: ""
company: ""
buyer_role: ""
signals:
  trigger: ""
  stack: ""
  hiring: ""
  news: ""
hipotesis_dolor: ""
research_resumen: ""
research_at: ""
usable: true|false
email: ""
verified_at: ""
verification_status: ok|fail|pending
sequence_draft:
  step1: ""
  step2: ""
  step3: ""
human_approval: pending|approved|rejected
send_status: not_sent|sent|replied|bounced
notes: ""

Dónde vive el contrato

• CRM custom fields + nota.
• O carpeta de archivos por account_id (piloto).
• O board simple (una fila = una cuenta).

Lo barato es el esquema. Lo caro es descubrir en el envío 200 que el Researcher escribió sobre la cuenta A y el Copywriter pegó en la B — exactamente el fallo que el contexto aislado multi-agente intenta evitar (Anthropic Docs).

Por qué el contrato vence al “buen prompt”

Un prompt brillante sin campos tipados no sobrevive al segundo humano del equipo. El Enricher no sabe qué mirar; el Sender no sabe qué aprobar; el CRM no sabe qué filtrar. El contrato convierte criterio editorial (usable, verified, approved) en algo que un filtro o un agente puede respetar. Si mañana cambias de LLM, el contrato sigue. Si cambias de sequencer, el contrato sigue. El prompt es desechable; el esquema no. En el piloto, resiste la tentación de “ya lo tenemos en el chat”. Baja el YAML o los campos al CRM aunque duela. El dolor de escribir account_id cinco veces es barato frente al dolor de no saber qué se envió.

¿Quieres un sistema con handoffs (no un chat que “hace outbound”)?

Si ya tienes prompts sueltos y el CRM no se entera, el siguiente paso no es otro modelo. Es roles + contrato + piloto en 5 cuentas con gate humano. ¿Quieres diseñar el sistema (roles + handoffs + gates) sin convertir agentes en spam autónomo? Habla con HelloMrLead Para material práctico de SDR: Recursos SDR

Qué cuenta como “handoff roto” (ejemplos)

• Researcher devolvió fluff y Copywriter lo usó igual.
• Enricher marcó fail y el draft igual llegó al sequencer.
• Faltaba account_id y se mezclaron notas de dos empresas.
• Humano “aprobó” sin leer (checkbox teatro).
• Reply negativo no actualizó estado en CRM.

Cada uno es un ticket de proceso, no un fallo del modelo. Arregla el contrato o el gate antes de pedir “más automatización”.

Piloto end-to-end en 5 cuentas (esta semana)

1. Elige 5 cuentas ICP reales.
2. Researcher → rellena señales + hipótesis (Issue 1).
3. Enricher → verified_at / email (Issue 2).
4. Copywriter → draft 3–4 pasos con slots obligatorios (Issue 3 — slug previsto; si aún no está live, aplica el estándar 3–4 + rechazo de genéricos).
5. Humano revisa → 1 envío (o secuencia corta low-volume).
6. Documenta handoff roto: ¿faltó campo? ¿fluff? ¿tool fail? ¿aprobación ambigua?

Métrica del piloto (única): número de handoffs rotos encontrados + tiempo hasta el primer envío aprobado. No “reply rate del piloto de 5” como prueba científica. Cinco cuentas no son un experimento de industria; son un detector de fricción.

Plantilla de post-mortem

• Cuenta / qué falló / en qué rol / fix / ¿bloquea scale?

Si no encuentras al menos un handoff roto, o no estás mirando o el piloto es teatro.

Observabilidad mínima (sin montar Datadog)

Para el piloto basta con tres preguntas al final del día:

1. ¿En qué rol se atascaron más cuentas?
2. ¿Cuántos drafts se rechazaron por fluff vs por falta de verified_at?
3. ¿Cuánto tardó el humano en aprobar el primer envío?

Si no puedes responderlas, no tienes orquestación: tienes archivos sueltos. La observabilidad no es vanity de “agentes lanzados”; es saber dónde se rompe el pegamento para no escalar la rotura.

Claude Code / Cowork como orquestador (categoría)

Categoría: entorno donde un coordinador puede lanzar skills/sub-tareas con herramientas (MCP, files, browser). El blog GTM de Anthropic describe skills de customer context, drafts, plugin en Cowork y revisión humana — el humano sigue en el loop (blog GTM). Las docs multiagent describen coordinador + roster, paralelismo y contexto aislado (docs). En este artículo explicamos el mapa de roles, no un tutorial de instalar keys ni de automatizar envío masivo. No afirmamos que HelloMrLead opere un stack multi-agente en producción para clientes.

Nodos del stack (categoría otra vez)

• Fetch web: Firecrawl / Apify (ejemplos)
• Email verify: BetterContact u otro (ejemplo)
• Sequencer: Instantly / HeyReach solo tras approval
• CRM: sistema de record del contrato

Ejemplos de categoría. No case studies inventados. No “stack HML oficial”.

Política mínima escrita (media página)

Antes de scale, escribe en una nota compartida:

1. Quién puede aprobar envíos.
2. Qué campos son bloqueantes (usable, verified_at, human_approval).
3. Qué pasa con bounce / “unsubscribe” / “left company”.
4. Quién puede subir volumen o añadir dominio al sequencer.

Sin esa media página, el multi-agente hereda la política implícita del chat de ayer — y esa política no escala.

Gobernanza: qué decide el humano siempre

No negociable (humano):

• Envío / no envío.
• Excepciones ICP.
• Respuesta a negative reply / legal.
• Subir volumen.
• Conectar dominio nuevo al sequencer.

Delegable al agente (con muestreo):

• Borradores.
• Resúmenes de fuentes públicas.
• Cola de enrichment.
• Flags usable/fluff (muestreados por humano).

Si el agente “puede enviar”, el día 1 no debería. El día 100, tampoco sin política escrita y métricas de queja/bounce. Orquestación ≠ autonomía ciega.

Cómo encaja la serie completa (1→4)

1. Research = señal + hipótesis (live)
2. Keep-alive = verified_at (enlace previsto — puede estar publicándose)
3. Secuencias = 3–4 pasos + ~20 antes de scale
4. Multi-agente = orquestación + handoffs

El cierre de la serie = conversación de servicios. Cruza también recursos SDR, consultoría de marketing y generación de leads y campañas salientes escalables. Woodpecker y Gong, ya citados en la serie, siguen aplicando al nodo Copywriter/Sender: personalización real vs fluff, copy corta, no pitch vacío (Woodpecker, 2026; Gong, 2025). El multi-agente no cambia esas reglas: las hace cumplibles a escala solo si el contrato las exige.

Señal de que estás listo para automatizar más (y cuándo no)

Listo (relativo): piloto 5 documentado, ≥1 handoff roto arreglado, gates 1–3 activos, humano lee replies, spam/bounce bajo control a alto nivel. No listo: “el agente genera 500 drafts esta noche”, send autónomo, sin account_id, midiendo éxito en tokens o emails generados. Automatizar un proceso roto multiplica la rotura. Orquestar un proceso sano multiplica el criterio.

Errores al “montar agentes”

• Dar al agente send autónomo.
• No versionar el brief de research.
• Sin account_id estable → caos.
• Medir éxito en “emails generados”.
• Saltar el piloto de 5.
• Mezclar datos de cuenta A en draft de cuenta B (contexto contaminado).
• Celebrar el plugin instalado sin gate human_approval.
• Confundir “Anthropic lo documenta” con “ya tengo RevOps”.
• Prometer internamente “piloto 5 = pipeline”.

Qué haría yo esta semana (checklist)

• <input type=»checkbox» disabled> Dibujar 4 roles en una hoja
• <input type=»checkbox» disabled> Definir contrato YAML/JSON mínimo
• <input type=»checkbox» disabled> Piloto 5 cuentas end-to-end
• <input type=»checkbox» disabled> Documentar ≥1 handoff roto
• <input type=»checkbox» disabled> Gate humano antes de send
• <input type=»checkbox» disabled> Gates Issue 1–3 activos en el flujo

Para quién es esto (y para quién no)

Sí: founders técnicos, RevOps y leads de outbound que ya juegan con agentes y necesitan un mapa de roles, no otro tutorial de un chat. Equipos que rompen en el handoff CRM ↔ sequencer. No todavía: quien no tiene ICP, research usable ni lista viva. Montar multi-agente sobre basura es orquestar el cementerio. Tampoco es para quien busca “el agente que cierra reuniones solo”: aquí el Sender es humano a propósito.

FAQ — Outbound multi-agente

¿Qué es outbound multi-agente?

Un sistema donde varios agentes (o skills) especializados colaboran —research, enrichment, draft— bajo un coordinador, con un humano que aprueba el envío.

¿Por qué no basta un solo chat?

Porque mezcla contextos, no deja contrato de datos auditable y empuja a enviar sin gates de calidad (usable research + verified_at).

¿Cuáles son los roles mínimos?

Researcher, Enricher, Copywriter (draft) y Sender humano. Un agente no debería ser los cuatro el día uno.

¿Qué es el “contrato de datos”?

El esquema mínimo (campos) que cada paso debe producir y consumir: señales, hipótesis, verified_at, draft, human_approval, send_status.

¿Claude Code o Cowork son obligatorios?

No. Son ejemplos de categoría de orquestador. El mapa de roles y el gate humano importan más que el logo (Anthropic GTM; docs multiagent).

¿Cómo empiezo sin montar infraestructura grande?

Piloto en 5 cuentas con archivos o campos CRM + revisión humana. Documenta roturas antes de automatizar. No uses reply rate de 5 envíos como prueba científica.

¿Sistema con handoffs o chat con disfraz de outbound?

¿Quieres diseñar el sistema (roles + handoffs + gates) sin convertir agentes en spam autónomo? Contacta con HelloMrLead Para material práctico de SDR: Recursos SDR