Product sheet
Outreach Machine automatiza el camino desde un CSV de empresas hasta una reunión agendada. Cada contacto atraviesa un pipeline estructurado: se resuelve la empresa, se descubren los decision-makers en LinkedIn, se valida el email, se puntúa contra tu ICP y se redacta la secuencia. El operador aprueba antes de que salga un solo mensaje.
El agente interviene donde el dato es ambiguo: califica si una empresa encaja en el ICP, redacta el primer borrador de la secuencia y clasifica las respuestas entrantes para saber cuáles escalar. En todo lo demás — classificación de títulos, validación de email, reglas de unsubscribe — el sistema es completamente determinista y auditable.
Goal: convertir listas frías en reuniones agendadas con un pipeline auditable donde el humano aprueba cada envío — maximizando deliverability y compliance sin sacrificar volumen.
Problema que resuelve
Las herramientas de outreach optimizan volumen y velocidad, pero dejan el control en manos del dato sucio y del envío automático: emails no validados que queman el dominio, sin trazabilidad de por qué un contacto entró a una secuencia, y unsubscribes que se ignoran. Outreach Machine v2 invierte la prioridad — control y auditoría primero, volumen después.
Tipos de usuario
SDR / Operador
Ejecuta el pipeline y trabaja la review queue: aprueba, rechaza o bloquea contactos antes del envío.
Growth / RevOps
Define el ICP y las secuencias, mide conversión y ajusta el scoring.
Admin de workspace
Gestiona tenancy, integraciones (Composio) y dominios verificados vía Clerk.
Agencia multi-cliente
Aísla cada cliente en su propia org con RLS y auditoría independiente.
Jobs to be done
Cuando tengo una lista de empresas target, necesito identificar a los decision-makers correctos
sin gastar horas buscando en LinkedIn manualmente ni arriesgar mi dominio con emails sin validar.
Cuando quiero lanzar una secuencia de outreach, necesito saber que cada email es entregable
antes de enviarlo, para proteger la reputación del dominio y no desperdiciar cuota de envío.
Cuando el agente redacta o califica un contacto, necesito revisar y aprobar antes de que salga algo
porque soy yo quien responde ante el cliente, no la IA.
Cuando llega una respuesta, necesito saber si es interés real, rechazo o un unsubscribe
para actuar de inmediato: agendar, cerrar o bloquear sin que nada se pierda en el ruido.
Cuando algo sale mal, necesito saber exactamente qué pasó, cuándo y por qué
para auditar, corregir y demostrar compliance — no adivinar a partir de logs parciales.
Cuando gestiono varios clientes o equipos, necesito que los datos estén completamente aislados
y que cada workspace tenga su propia configuración de ICP, secuencias y credenciales.
Capabilities & features
El pipeline en un vistazo
Reglas load-bearing (no negociables)
Aprobación manual obligatoria
Ningún code path envía sin pasar por la review queue. El agente propone; el humano aprueba.
Unsubscribe es terminal
contact_status = 'blocked' y se detienen todos los enrollments en una sola transacción.
Verified fields inmutables
Nunca se sobreescribe un campo verificado. Se chequea verified_fields antes de cada write.
Audit-first
Cada cambio de estado escribe un contact_event; cada acción de actor, un system_event.
Garantías operativas
Async ops
100% jobs
Idempotencia
By design
Tenancy
RLS + FKs
Email gate
Validado
Benchmark against competitors
Las plataformas de sales-engagement automatizan el envío. Outreach Machine v2 antepone control, auditoría y propiedad del dato: pipeline determinista, gate de aprobación humana y un agente que razona pero nunca dispara.
| Capacidad | Outreach Machine v2 | Outreach / Salesloft | Apollo.io | Clay | Instantly / Smartlead |
|---|---|---|---|---|---|
| Data & discovery | |||||
| Import de contactos (CSV / bulk, idempotente) | Nativo | ||||
| Company resolution automática (dominio → datos) | Nativo | Parcial | via enrichment | ||
| LinkedIn decision-maker discovery | Bright Data | Add-on | via enrichment | ||
| Title classification rule engine (ES + EN, sin LLM) | Nativo | Básico | Básico | ||
| ICP scoring configurable por workspace | Nativo | Limitado | |||
| Email & deliverability | |||||
| Email resolution (Hunter) | Hunter | Propio | Propio | via enrichment | |
| Validación de email que bloquea enrollment | NeverBounce | Opcional | |||
| outreach_ready como view computada (nunca almacenada) | Nativo | ||||
| Sequencing & sending | |||||
| Secuencias multi-step con delays y condiciones de salida | Nativo | ||||
| Template versioning (draft → approved) | Nativo | ||||
| Review queue — aprobación humana obligatoria antes de enviar | Forzada | Opcional | Opcional | ||
| Unsubscribe terminal (blocked irreversible + stop de enrollments) | Nativo | ||||
| Reply management & CRM | |||||
| Clasificación de replies 3 tiers (regex + keyword + agente) | Nativo | Básico | Básico | ||
| CRM sync (HubSpot) | Composio | Nativo | Nativo | Zapier | |
| Calendar booking automático (Google Calendar) | Composio | ||||
| Intelligence & agent | |||||
| Agente con juicio en pasos difusos (ICP, drafting, replies) | Anthropic SDK | AI add-on | AI add-on | AI cols | |
| Interfaz en lenguaje natural para el operador | Nativo | ||||
| MCP server + client (bidireccional) | Nativo | ||||
| Compliance, audit & platform | |||||
| Audit-first (event append-only por cada cambio de estado) | Nativo | ||||
| Pipeline determinista + state machine auditable | Nativo | ||||
| Propiedad del dato (Postgres propio + RLS por tenant) | Nativo | SaaS | SaaS | SaaS | SaaS |
| Multitenancy nativo (Clerk Orgs + Verified Domains) | Nativo | ||||
| Feature flags por workspace | Nativo | ||||
nativo · parcial / add-on · no disponible. Posicionamiento cualitativo según contratos y modelo de producto, no un benchmark de performance.
Strategic vision
Las herramientas actuales de AI SDR resuelven el problema equivocado: automatizan el envío pero no el pensamiento. Estas cinco capacidades son la diferencia entre una herramienta de outreach y un sistema de GTM.
Historical layer — memoria de cuenta, contacto y organización
El feature más ausente en los AI SDR actuales. La memoria convierte cada interacción en contexto acumulado que los competidores no pueden copiar.
Account memory
- Campañas anteriores y sus resultados
- Mensajes que ya se enviaron
- Objeciones recibidas y cómo se respondieron
Contact memory
- Historial de replies y tono de cada uno
- Contenido con el que interactuó
- Perfil de personalidad inferido
Organization memory
- Qué mensajes, canales y timings convierten mejor
- Qué segmentos responden más
- Qué no funciona y por qué
Strategy agent — decide la estrategia, no solo el mensaje
Las herramientas actuales preguntan "¿qué mensaje envío?". La pregunta correcta es "¿qué estrategia corro para esta cuenta?".
Herramientas actuales
- ¿Qué email envío ahora?
- ¿Cuántos follow-ups programo?
- ¿Cuál es el mejor subject line?
Strategy agent
Experimentation agent — multi-armed bandit, no A/B testing
El A/B testing clásico es estático y lento. Un agente de experimentación aprende y ajusta continuamente sin intervención manual.
A/B testing clásico
- Define variante A y B manualmente
- Espera N semanas para significancia estadística
- Aplica el ganador — hasta el próximo test
- Optimiza una variable a la vez
Multi-armed bandit agent
- Aprende continuamente qué ICPs convierten
- Aprende qué señales predicen respuesta positiva
- Aprende qué ángulos de mensaje funcionan por segmento
- Aprende qué canales y timings convierten más
- Ajusta automáticamente la distribución de recursos
Trigger marketplace — señales de intención accionables
Regie tiene 100+ señales. El mercado irá mucho más lejos: los usuarios necesitan crear sus propios triggers sobre cualquier dato público o privado.
Señales de empresa
- Ronda de financiamiento
- Cambio de liderazgo (CXO nuevo)
- Lanzamiento de producto
- Adopción de competidor
- Cambio en pricing page
- Job posting relevante
Señales de contacto
- Aparición en podcast
- Post viral en LinkedIn
- Review en G2 / Capterra
- Cambio de empresa o rol
- Cambio en website
Triggers custom
- El usuario define cualquier condición sobre datos propios o externos
- El agente actúa cuando se cumple el trigger
- Cada trigger tiene su propia estrategia de respuesta
GTM operating system — más allá del outbound
Todos los competidores se enfocan en outbound. La oportunidad real es ser el sistema operativo de revenue: desde account planning hasta el next step después de la reunión.
Competitors focus on
- Outbound email
- Sequence automation
- Email personalization
GTM OS covers
- Account planning y priorización
- Prospecting multi-canal
- Outreach y follow-up
- Meeting prep (contexto + agenda)
- CRM updates automáticos post-call
- Next-step recommendations
Agentic layer and integrations
Un agente interno (Anthropic Agent SDK, modelo Claude más reciente) corre como apps/agent en Fly.io. Es a la vez tool user y endpoint MCP: otros agentes pueden invocar nuestras capacidades de outreach como herramientas, en ambas direcciones.
Domain tools
Wrappers tipados sobre packages/core + Supabase: consultar contactos/empresas, encolar jobs, qualify/classify/score, redactar secuencias, leer ICP.
Composio tools
OAuth gestionado: HubSpot, Google Calendar, Slack, Gmail/Outlook y la long tail. Toolset dinámico por workspace.
MCP client + server
Conecta a MCP servers externos que traiga el usuario y expone el suyo propio. CORS con allow-list, nunca *.
Dónde actúa el agente
Calificación ICP
Juicio sobre empresa/perfil con reglas LLM dentro del ingest Stage-B.
Redacción de secuencias
Genera versiones draft que requieren aprobación antes de cualquier envío.
Desambiguación de replies (Tier 3)
Razona con labels ricos y un mapping los colapsa a los 4 valores canónicos.
Requests NL del operador
"Encuentra 50 más como estos" — su superficie de lenguaje natural.
Lo que nunca hace
Saltar la aprobación de envío
Regla 6 — manual approval mandatory. Propone, no dispara.
Reactivar un unsubscribe
Regla 7 — el estado blocked es terminal.
Sobreescribir verified fields
Regla 1 — inmutabilidad de los campos verificados.
Clasificar títulos en runtime
Story 4 es rule-based; el agente solo sugiere reglas a aprobar.
Integraciones — Composio vs adaptadores directos
Composio — OAuth gestionado
OAuth, refresh de tokens y breadth los gestiona Composio.
Adaptadores directos — packages/providers
Alto volumen, determinista, con captura de raw payload a Storage antes de parsear y rate-token antes de la llamada.
Tech stack
Monorepo pnpm + Turborepo, Node 20 LTS, TypeScript en todas partes, Zod everywhere. Una sola fuente de verdad para secrets (Doppler) y para la identidad (Clerk, a través de packages/auth).
Frontend
- Next.js 14 — App Router, RSC, Server Actions
- Tailwind + shadcn/ui
- TanStack Query — server state
- Zustand — UI state
- Deploy en Vercel
Backend & runtime
- Fly.io —
apps/workerjob executors - Fly.io —
apps/agent+ MCP server - Anthropic Agent SDK
- Composio — OAuth integrations
Datos & estado
- Supabase Postgres + RLS
- Realtime — live pipeline UI
- Storage — raw payloads
-
jobsqueue + Edge Functions
Identidad & secrets
- Clerk — Orgs + Verified Domains
- Doppler — única fuente de secrets
- RLS lee el org activo del JWT
- Zod — contratos compartidos
Layout del monorepo
apps/
web · worker · agent
packages/
core · providers · db · jobs · auth · schemas · integrations
skills/
playbooks markdown del agente
supabase/
migrations · edge functions
Detalle arquitectónico
Tres planos de ejecución coordinados por una cola de jobs en Postgres. El estado vive en un solo lugar (Supabase); Vercel sirve la UI, Fly.io corre el trabajo largo, y Clerk + Doppler eliminan el plumbing de tenancy y secrets.
Topología runtime — color por sistema: purple Clerk · amber Doppler · gray Vercel · green Supabase · violet Fly.io · orange Composio
Responsabilidades por plano
Vercel
Next.js FE, Server Actions, webhook routes rápidas (<1s). BFF para la UI.
Supabase
Postgres+RLS, Realtime, Storage, cola jobs, Edge Functions (cron tick + webhooks ultra-rápidos).
Fly.io
Job executors + agent runtime. Sin techo de tiempo de ejecución; mantiene contexto del agente; escala a cero.
Clerk
Identidad, Organizations (tenant), Verified Domains. Borra el código custom de org/invite/domain.
Composio
OAuth gestionado (HubSpot, Calendar, Slack, long tail). El agente recibe tools dinámicas.
Doppler
Secrets para todo lo anterior, por ambiente (dev/stg/prd). Sync nativo, sin duplicación manual.
Flujo canónico
→ cron tick despacha → Fly worker reclama
→ corre pure logic + provider/Composio → persiste + emite contact_event
→ Realtime empuja el status a la UI
Multitenancy — la gran simplificación
El tenant es una Clerk Organization. La app nunca construye membership, roles, invites ni domain allow-lists. El org activo viene de la sesión (JWT org_id), nunca de la URL — las URLs no llevan slug. En la DB, workspaces es una proyección read-only de las orgs de Clerk, sincronizada por webhook. RLS colapsa a "el workspace cuyo clerk_org_id = el org activo de la sesión".
Máquina de estados del contacto
El pipeline se mantiene determinista de punta a punta. El agente añade juicio solo en los pasos difusos y jamás puentea los gates duros (aprobación, unsubscribe, verified fields).