Agente de IA para ventas outbound: lecciones de arquitectura que todo equipo técnico debe conocer
Hay una frase que muchos ingenieros reconocerán de inmediato: "soy desarrollador, no vendedor". Es exactamente lo que dijo el creador de LeadAce antes de construir un agente de inteligencia artificial que hace prospección comercial en su lugar. Lo interesante no es que el agente funcione — es cómo está construido y qué decisiones de arquitectura lo hacen confiable, seguro y replicable.
Publicado como código abierto en agosto de 2026, LeadAce es un plugin para Claude Code que encuentra empresas que encajan con tu perfil de cliente ideal, lee su sitio web, redacta un email personalizado por empresa, lo envía desde el Gmail del usuario y clasifica las respuestas. Pero lo que convierte este proyecto en un caso de estudio valioso es la forma en que resuelve el problema más difícil de los agentes de IA: ¿qué debe decidir el modelo y qué debe ser código fijo?
En este artículo analizamos las tres decisiones de arquitectura más importantes del proyecto y cómo aplican directamente a empresas en Perú y LATAM que están considerando construir o adoptar agentes de IA en sus procesos comerciales.
1. El boundary de confianza: la decisión más importante en cualquier agente de IA
El equipo de LeadAce estableció una regla clara para dividir responsabilidades dentro del agente. Las herramientas del lado del servidor — escritura en base de datos, validaciones de cumplimiento, listas de no-contacto — son código determinístico que el modelo de IA no puede modificar. El modelo llama a una función como record_outreach pero nunca ve las doce reglas de validación detrás de ella.
Las herramientas del lado del usuario — envío de emails desde Gmail, navegación web, automatización del navegador — corren en la máquina del usuario para que el email salga realmente desde su propia bandeja de entrada. Y el modelo de lenguaje solo toma decisiones de calidad y criterio: leer el sitio de una empresa, elegir el ángulo del email, clasificar una respuesta como rechazo por precio o por timing.
La razón detrás de esta separación es crítica: el agente lee sitios web de empresas desconocidas todo el día. Cualquiera de esos sitios podría contener contenido diseñado para manipular al modelo — lo que se conoce como prompt injection. Si el modelo pudiera modificar reglas de envío o acceder directamente a la base de datos, un sitio malicioso podría explotarlo. Al mantener todo lo que toca datos o envíos como código fijo, el boundary de confianza queda protegido.
2. Los rechazos como datos: el diferencial real del producto
Las tasas de respuesta en outbound frío están en un dígito. El creador del proyecto lo dice sin rodeos: el pitch no es "10x más respuestas". El pitch es que los "no" vuelven como información estructurada en lugar de silencio.
Cada rechazo se clasifica automáticamente en categorías: presupuesto insuficiente, timing incorrecto, persona equivocada, funcionalidad faltante. Esa información alimenta directamente la siguiente ronda de prospección — ajustando el targeting, el mensaje o el momento de contacto. El agente aprende de los rechazos en lugar de ignorarlos.
Esto cambia fundamentalmente la economía del outbound. En lugar de acumular silencio, acumulas inteligencia comercial. Para una empresa mediana en LATAM que hace prospección manual hoy, este enfoque representa una ventaja operativa concreta: cada campaña es más precisa que la anterior porque los datos de rechazo alimentan el sistema.
3. Multi-tenancy con Row-Level Security: cien líneas que valen su peso en oro
Cuando un sistema maneja listas de prospectos y hilos de email de múltiples clientes, el aislamiento de datos no es opcional. LeadAce implementa Row-Level Security en PostgreSQL con una configuración de aproximadamente cien líneas de código. Cada tabla tiene un tenant_id y cada transacción establece el contexto del inquilino antes de ejecutar cualquier consulta.
El punto más inteligente de esta implementación es que el RLS actúa como red de seguridad — no como mecanismo principal de consulta. Los handlers de rutas siguen escribiendo queries filtradas normalmente. El RLS es lo que los salva el día que un handler olvida el WHERE. Para productos que manejan datos sensibles de terceros, esta es la diferencia entre un incidente de seguridad y una noche tranquila.
¿Cómo aplica esto en tu empresa?
Si tu empresa está evaluando construir agentes de IA para procesos comerciales, de soporte o de operaciones, las lecciones de LeadAce son directamente aplicables independientemente del sector o tamaño.
Lo primero es mapear el boundary de confianza antes de escribir una sola línea de código. Define explícitamente qué puede decidir el modelo y qué debe ser código determinístico. Si un error en esa decisión puede causar un problema de datos o cumplimiento, debe ser código. Si solo causa un problema de calidad, el modelo puede manejarlo con gates de revisión humana.
Lo segundo es diseñar para aprender de los errores. Un agente que solo ejecuta tareas es una automatización. Un agente que convierte cada resultado — incluyendo los negativos — en datos estructurados que mejoran la siguiente ejecución, es un sistema que se vuelve más valioso con el tiempo. Esa diferencia es la que justifica la inversión.
Lo tercero es tratar la seguridad multi-tenant como un requerimiento desde el día uno. En empresas que manejan datos de múltiples clientes o unidades de negocio, implementar Row-Level Security desde el inicio es significativamente más barato que añadirlo después. Cien líneas de configuración hoy pueden evitar una brecha de datos que cuesta meses de trabajo y reputación.
En Consultoría-Ti hemos trabajado con empresas en Perú y LATAM que están en diferentes etapas de adopción de IA — desde automatizaciones simples con n8n hasta integraciones más complejas con Claude API y Odoo. La experiencia nos dice que las empresas que avanzan más rápido no son las que tienen el presupuesto más grande, sino las que toman mejores decisiones de arquitectura desde el inicio.
Conclusión
LeadAce es interesante no porque automatice el outbound — hay docenas de herramientas que hacen eso. Es interesante porque documenta de forma honesta las decisiones de arquitectura que hacen que un agente de IA sea confiable, seguro y útil en producción. El boundary de confianza, el aprendizaje de rechazos y el aislamiento de datos son principios que aplican a cualquier agente de IA, en cualquier industria.
Si tu empresa está considerando construir o adoptar agentes de IA para procesos comerciales u operativos, el momento de definir la arquitectura correcta es antes de empezar a construir. Ese es exactamente el tipo de conversación que hacemos en Consultoría-Ti.
¿Quieres explorar cómo un agente de IA bien diseñado puede integrarse con tus sistemas actuales — incluyendo Odoo u otras plataformas que ya uses? Conversemos sin compromiso.
Fuentes y Referencias
Dev.to — Building an outbound sales agent as a Claude Code plugin (and open-sourcing it)
✨ Contenido generado con ContentFlow — Consultoría-Ti