Traspaso de agentes IA en WhatsApp sin perder contexto
Aprende a transferir conversaciones entre agentes de IA en WhatsApp sin que el cliente repita nada. Arquitectura, prompts y errores a evitar.
Hay un momento concreto en el que la automatización pierde la confianza del cliente: cuando le preguntan otra vez su nombre, su pedido o el problema que acaba de explicar. No importa que la primera parte de la conversación haya sido perfecta. El traspaso lo arruina todo.
Esto ocurre casi siempre entre agentes de IA, no entre humanos. Cuando un bot de ventas deriva a un bot de soporte, o cuando el agente de calificación pasa la conversación al agente que agenda, lo habitual es que el segundo empiece desde cero. El resultado: fricción, repetición y clientes que abandonan.
Esta guía es para que eso no pase.
Por qué los traspasos entre agentes pierden contexto
La raíz del problema no es técnica, es de diseño. La mayoría de los sistemas de agentes IA tratan cada agente como una unidad independiente con su propia memoria. Cuando uno termina y el otro empieza, no hay un canal formal para transferir lo que se sabe del cliente.
Los tres puntos de falla más comunes son:
- Memoria aislada por sesión: el agente receptor no tiene acceso al historial del agente que entregó.
- Ausencia de resumen estructurado: incluso cuando existe un log de conversación, el segundo agente recibe texto crudo sin jerarquía de información.
- Prompts que no consumen contexto: el agente receptor está instruido para saludar y preguntar, no para leer un briefing antes de responder.
El cliente no ve agentes. Ve una sola conversación. El sistema tiene que estar diseñado desde esa perspectiva.
La arquitectura que hace el traspaso invisible
1. Un objeto de contexto compartido
Antes de cualquier lógica de agentes, define un objeto de contexto que persiste durante toda la sesión. Piénsalo como un expediente del cliente que viaja con la conversación.
Cada agente lee este objeto al iniciar y lo actualiza antes de ceder el turno. El agente receptor nunca arranca desde cero; arranca desde donde el otro paró.
2. Un resumen de traspaso generado automáticamente
Justo antes de que el agente A transfiera al agente B, debe generar un resumen estructurado. No es el historial completo; es lo relevante para que el siguiente agente pueda actuar de inmediato.
Un resumen bien formado incluye:
- Qué quería el cliente al inicio
- Qué información ya se recopiló (nombre, pedido, motivo)
- Qué se prometió o quedó pendiente
- El tono de la conversación (¿está frustrado, urgente, tranquilo?)
Esto puede generarse con un prompt interno —invisible para el cliente— que el orquestador ejecuta entre agentes.
3. Un orquestador que decide y transfiere
El orquestador es la capa que coordina qué agente está activo en cada momento. Su trabajo es:
- Detectar que el agente A llegó a su límite de competencia.
- Ejecutar el prompt de resumen.
- Pasar el objeto de contexto actualizado al agente B.
- Activar el agente B con ese contexto ya cargado.
Sin orquestador, el traspaso depende de que cada agente sepa cuándo y cómo ceder, lo cual es frágil por diseño.
Cómo estructurar los prompts para que el receptor no repita preguntas
El prompt de sistema del agente receptor es donde más se puede perder o ganar. Hay dos patrones que funcionan bien:
Patrón "briefing primero"
El system prompt del agente B empieza con una sección de contexto dinámico que se inyecta en cada traspaso:
Contexto de conversación anterior:
- Cliente: {{nombre}}
- Quería: {{intención_inicial}}
- Ya informó: {{datos_recolectados}}
- Resumen del agente anterior: {{resumen_agente_anterior}}
A partir de aquí tú continúas. NO vuelvas a pedir información que ya está en el contexto.
Empieza confirmando brevemente que entendiste la situación y ofrece el siguiente paso.
Patrón "confirmación ligera"
En lugar de ignorar el traspaso (lo que puede sentirse extraño) o preguntar todo de nuevo (que es el error clásico), el agente B hace una micro-confirmación:
"Entiendo, estás consultando sobre tu pedido #4521 que llegó incompleto. Voy a revisar eso contigo ahora mismo."
Esta línea hace dos cosas: demuestra que sí leyó el contexto y reencuadra la conversación sin fricción. Un par de líneas bien escritas en el prompt de sistema pueden generar esa respuesta de forma consistente.
Tabla: qué debe transferirse y qué puede omitirse
| Dato | ¿Transferir? | Por qué |
|---|---|---|
| Nombre y canal de contacto | Sí, siempre | Evita preguntar lo básico |
| Intención original del cliente | Sí, siempre | El agente B necesita saber el punto de partida |
| Historial completo de mensajes | Opcional | Puede ser ruido; mejor un resumen |
| Datos ya validados (email, pedido, etc.) | Sí, siempre | No repetir validaciones |
| Tono emocional de la conversación | Sí, si es relevante | Un cliente frustrado merece respuesta diferente |
| Mensajes de sistema internos | No | No son relevantes para el siguiente agente |
Los errores de diseño que destruyen la experiencia
Asumir que el historial es suficiente
Pasar el log crudo al siguiente agente no es lo mismo que pasarle contexto útil. Un modelo de lenguaje puede procesar un historial largo, pero en la práctica el ruido dificulta la síntesis. El resumen estructurado es más confiable que el historial completo.
No indicarle al agente B cuándo ya tiene información
Si el prompt no dice explícitamente "no preguntes lo que ya está en el contexto", el agente puede preguntar de todas formas porque está optimizado para recopilar datos. La instrucción negativa es tan importante como la positiva.
Traspasos en medio de una frase de acción
Si el agente A estaba a punto de darle una respuesta al cliente y el orquestador transfiere antes de que esa respuesta salga, el cliente queda en silencio. El traspaso debe ocurrir en un punto de cierre natural —después de que el agente A confirme o resuma— no a mitad de flujo.
No registrar el traspaso en el CRM
Cada vez que ocurre un traspaso entre agentes es una señal operativa valiosa. ¿Cuántas conversaciones requieren más de un agente? ¿En qué punto del flujo sucede? Sin ese registro, no puedes mejorar el diseño.
Un flujo concreto, paso a paso
Supongamos que un cliente escribe para preguntar por el estado de su pedido, pero al hablar con el agente de soporte resulta que quiere también cotizar un producto adicional. El agente de soporte detecta la señal de compra y debe transferir al agente de ventas.
- Agente de soporte (OlivIA) confirma el estado del pedido y detecta interés de compra.
- El orquestador ejecuta el prompt de resumen interno: "Genera un resumen del cliente y de su situación actual en 3-5 líneas, incluyendo el pedido consultado y el producto de interés mencionado."
- El resumen se escribe en el objeto de contexto compartido.
- El orquestador activa a ValerIA (agente de ventas) con ese contexto ya cargado.
- ValerIA saluda con una confirmación ligera: "¡Perfecto! Vi que tu pedido #4521 ya está en camino. También me comentaste que te interesa el modelo X, te explico cómo conseguirlo."
El cliente nunca supo que hubo un cambio de agente. Eso es el objetivo.
Pruébalo en tu negocio
En Lead Lab AI, ValerIA y OlivIA comparten contexto en tiempo real: si una conversación pasa de ventas a soporte —o al revés—, el agente receptor ya sabe quién es el cliente, qué quería y qué quedó pendiente. Sin repeticiones, sin fricción.
¿Quieres ver cómo se aplica esto a tu negocio? El primer paso es una llamada de unos 20 minutos con un experto de Lead Lab AI: revisamos tu caso, conectamos tu WhatsApp y te dejamos lista tu prueba gratis de 7 días. Agenda con un experto o escríbenos a hola@lead-lab.ai.
¿Listo para que la IA atienda por ti?
ValerIA vende y OlivIA da soporte — por WhatsApp, voz y chat web, conectadas a tus datos. Una llamada con un experto y tu prueba de 7 días queda lista.