Servicare — agente IA (WhatsApp + Kommo)

Agente conversacional multimodal por WhatsApp para una empresa de salud ocupacional en Colombia. Vive entero en un Cloudflare Worker —es el canal y el cerebro a la vez— y refleja cada conversación y cada lead en Kommo, el CRM donde el equipo comercial ya trabaja. El humano no cambia de herramienta; la IA atiende la primera línea. Y cuando una persona retoma, responde en texto libre y con todo el contexto del hilo —sin las plantillas rígidas que cobra WhatsApp.

Stack: Cloudflare Workers · Durable Objects · Gemini multimodal · WhatsApp Cloud API · Kommo CRM (API + webhooks) · KV · TypeScript · Estado: en construcción (motor verificado, integración Kommo en curso) · Rol: arquitectura + desarrollo (solo)

El problema

La empresa atiende dos verticales bajo una marca —exámenes de salud ocupacional y un centro de reconocimiento de conductores— y captaba todo por WhatsApp a mano: una persona respondiendo, copiando datos a un CRM, perdiendo mensajes en horas pico. Querían un agente que atendiera 24/7, entendiera la nota de voz o la foto del documento que manda el cliente, y —esto es lo que de verdad pedían— que no los obligara a aprender un sistema nuevo: su operación comercial ya vivía en Kommo.

El reto no era “poner un bot”. Era meter un agente de IA delante de un CRM existente sin romper el flujo de trabajo del equipo humano, y hacerlo con datos sensibles (Ley 1581 / Habeas Data) sin fugarlos.

Qué construí

Un agente sobre mi propia plataforma de WhatsApp (un fork del motor en Cloudflare Workers + Durable Objects + Gemini), configurado para este dominio. El Worker es canal y cerebro: recibe el webhook de WhatsApp, agrupa los mensajes del cliente, razona con Gemini sobre texto + audio + imagen en un solo turno, y responde. Sobre eso, la pieza que define el proyecto:

El espejo a Kommo. Cada conversación se refleja como un lead en Kommo: el agente crea el contacto, lo mueve por el pipeline (nuevo → calificado → handoff) y escribe las notas, mientras el equipo comercial sigue trabajando en la interfaz de Kommo que ya conoce. Cuando un humano toma la conversación desde Kommo, el agente se apaga solo para ese hilo. El bot atiende la primera línea; la persona cierra. Ninguno pisa al otro.

Decisiones de arquitectura interesantes

Worker = canal + cerebro; Kommo = la verdad comercial (ensamblaje deliberado). Había dos formas de armarlo: que Kommo fuera el canal (su integración nativa de WhatsApp) con la IA colgada detrás, o que el Worker fuera dueño del canal y espejara a Kommo. Elegí lo segundo. Razón: el control del canal es donde vive la lógica difícil —batching de mensajes, contexto multimodal, la ventana de 24h de WhatsApp, el apagado por handoff— y eso no se puede expresar bien dentro de un CRM. Kommo queda como la fuente de verdad comercial (leads, pipeline, tareas del vendedor), que es justo para lo que es bueno. Cada herramienta hace lo que hace mejor.

Handoff sin carreras, gobernado desde el CRM. El agente solo actúa mientras el lead está en su etapa automática. En cuanto un humano lo mueve o responde desde Kommo, un webhook marca la conversación y el bot se silencia para ese contacto. No hay el clásico choque de “el bot y el vendedor contestando a la vez”.

Retoma dentro de la ventana de 24h, en texto libre. La WhatsApp Business API solo deja escribir fuera de la ventana de servicio con plantillas pre-aprobadas y pagadas por mensaje —texto rígido, sin libertad para responder lo que el cliente preguntó. Muchas plataformas empujan al humano a esas plantillas incluso dentro de la ventana, o lo sacan a otra bandeja sin el historial. Aquí es al revés: como el Worker es dueño del canal y conserva cada turno, el humano que toma el lead desde Kommo responde en lenguaje natural, dentro de la ventana, con el contexto completo de lo que la IA ya conversó —incluidas las notas de voz y las fotos del documento. El relevo de IA a persona es invisible para el cliente, y no se gasta una plantilla rígida en algo que la ventana abierta resuelve mejor y gratis.

Aislamiento multi-tenant duro. El motor sirve a varios clientes; cada tenant es una fila de configuración (prompt, servicios, horarios, credenciales de su propio WhatsApp y su propio Kommo) más sus datos aislados. Las credenciales de un cliente nunca son alcanzables desde el contexto de otro: el aislamiento es una invariante del código, no una convención. Cliente nuevo = configuración, no un fork.

Habeas Data desde el diseño. Son datos de salud. El motivo de consulta y los documentos sensibles no viajan en notificaciones ni se exportan a terceros sin control; el agente registra consentimiento y respeta retención. La integración con Kommo lleva solo lo que el flujo comercial necesita, no el expediente clínico.

El LLM es una fuente de entrada no confiable. Lo que el modelo “decide” (un servicio, una fecha, un dato del cliente) se valida antes de escribirlo en Kommo o en la base: si alucina, re-pregunta, no inserta. La misma frontera de validación que aplicaría a un humano.

Arquitectura

Qué demuestra

• Integro IA con el sistema que el cliente ya usa, en vez de obligarlo a migrar: el equipo comercial nunca sale de Kommo.
• Sé dónde poner cada responsabilidad: el canal y el razonamiento en el edge, la verdad comercial en el CRM. El ensamblaje es una decisión, no un accidente.
• Handoff humano-IA bien resuelto, gobernado por el estado del CRM, sin carreras.
• Multi-tenant con aislamiento real y compliance de datos de salud tratado como arquitectura.

Estado y siguiente paso

El motor está verificado (canal de WhatsApp del cliente, almacenamiento y cerebro Gemini respondiendo); la integración con Kommo —creación y movimiento de leads, webhooks de handoff— está en construcción sobre esa base. El cliente arrancó el día 1 sobre el bot nativo de su CRM; este agente es la graduación cuando el volumen lo justifique. Es parte de un ecosistema más amplio para el mismo cliente —el portal B2B es el otro componente— que a futuro converge en una sola plataforma.