Agente IA de WhatsApp para e-commerce: cómo lo estamos construyendo

Qué es un agente IA de WhatsApp (y por qué no es un chatbot)

La palabra "chatbot" se usa para dos cosas que técnicamente no se parecen. Un chatbot de árbol de decisión es un mapa de respuestas: el cliente escribe una palabra clave, el sistema matchea un disparador y devuelve una respuesta cargada de antemano. Es rápido y predecible, pero se rompe en cuanto el cliente sale del guión o hace una pregunta compuesta.

Un agente IA es otra cosa. Lee el historial completo, interpreta la intención, consulta sistemas externos cuando le hace falta y elige la acción sin un flujo rígido. La diferencia práctica para un gerente de operaciones: el chatbot responde preguntas sueltas, el agente conduce una conversación de punta a punta.

El agente que estamos construyendo usa agentes IA con Claude Code y el SDK de Anthropic con tool use nativo. No es un wizard de "armá tu bot sin código": es un sistema de software con su loop de razonamiento, su base de conocimiento y su registro de auditoría.

El cliente es una empresa de retail y e-commerce que opera en Ecuador, con planes de expandir a más países de la región. Su atención al cliente vive en WhatsApp: consultas de productos, estado de pedidos, envíos, postventa. Ya tienen un CRM maduro con pipelines de ventas y soporte que funcionan, y un equipo mayormente no técnico que responde desde ese CRM.

El objetivo no es reemplazar a ese equipo, sino sacarle de encima el volumen repetitivo (las mismas preguntas sobre envíos, horarios, disponibilidad) y dejar que las personas se concentren en los casos que de verdad necesitan un humano. Tres restricciones marcaron todo el diseño:

• No tocar lo que ya funciona. Los pipelines del CRM están maduros. El agente se suma como una capa, no reordena el flujo de trabajo existente.
• El equipo lo tiene que poder operar sin nosotros. En el mes 12, sin Duotach en el medio, el cliente tiene que poder editar respuestas, ajustar reglas y entender qué pasó en cada conversación.
• Multi-país desde el diseño. Lo que se construye para un país tiene que escalar a otros, con contenido y tono distintos por mercado.

Cuando una decisión es load-bearing (sostiene el resto del sistema durante meses), en Duotach la pasamos por un análisis formal de alternativas antes de comprometernos. Estas son las tres que definieron el agente.

El sistema se piensa por capas. Cada una tiene una responsabilidad clara y le habla solo a la de al lado.

Sobre el modelo: usamos Claude con un mix optimizado por costo. Sonnet 4.5 como modelo principal para razonamiento y conversación; Haiku 4.5 para clasificación y FAQs simples. El SDK base de Anthropic da tool use nativo, prompt caching y streaming sin meter el harness completo de Claude Code en producción, que para un agente conversacional sería over-tooling.

Las herramientas (tools) que el agente puede invocar en esta primera fase:

• search_knowledge_base — busca en el KB filtrado por país cuando necesita info que no entró en el contexto inicial.
• lookup_contact_kommo — trae el historial reciente y los datos del contacto desde el CRM.
• handoff_to_human — marca la conversación para derivar a un humano, con motivo, urgencia e intención para el routing.

En el roadmap suman lookup_order_status (estado de pedido), create_lead_kommo (crear lead ante intención de compra clara) y escalate_with_context (handoff con resumen estructurado). Si te interesa el patrón general detrás de esto, lo desarrollamos en nuestra guía de agentes IA con Claude Code.

Cómo se resuelve una conversación, paso a paso

El flujo conceptual de un turno, de punta a punta:

Cliente (WhatsApp)
   ↓
Wazzup → Kommo (Salesbot dispara webhook)
   ↓  widget_request (ack < 100 ms, timeout 2s mitigado async)
n8n: intake + buffering por chat_id + lookup de contacto
   ↓  POST /turn { chat_id, country, messages, contact_id }
Servicio Node (loop de agente):
   1. Embed de la consulta
   2. Retrieval híbrido (pgvector + tsvector) por país
   3. Carga del system prompt activo del país
   4. Llamada a Claude con tools
   5. Loop multi-turn mientras pida herramientas
   6. Escritura del audit_log
   ↓  { response_text, side_effects }
n8n: responde al cliente + ejecuta side effects en el CRM
   ↓
Cliente recibe la respuesta en WhatsApp

Cada turno queda registrado: qué documentos se recuperaron, qué herramientas se llamaron, qué prompt se usó, cuántos tokens y cuánta latencia. Ese audit log por turno, guardado en Postgres y visible desde el admin, es mejor trazabilidad que la UI de un workflow para la pregunta que de verdad importa: "¿por qué el agente respondió esto?". Es queryable, exportable y no se rota a los pocos días.

Qué viene después

Cuando el agente esté estable en producción y tengamos datos reales (volumen resuelto sin humano, tiempos de respuesta, CSAT), vamos a publicar el caso de éxito completo con números. Por ahora, lo que podemos mostrar es el criterio. Si querés ver el resto de lo que construimos, está en nuestros casos de éxito. Y si todavía no estás en este nivel pero querés empezar por la base, escribimos una guía para automatizar WhatsApp Business con n8n.

Preguntas Frecuentes