El error antes de todos los errores
El que explica por qué cometí todos los demás.
Todo lo que encontré sobre voice agents con Retell AI, N8N y Cal.com eran demos, tutoriales en preproducción, casos ideales. Copié, pegué, adapté. En preproducción funcionaba. Lo subí a producción: se rompió en 20 minutos. Tuve que quitarlo de urgencia.
No existía documentación honesta del salto a producción real. Los creadores de contenido muestran el caso feliz, sin carga, sin usuarios reales, sin los mil matices que aparecen cuando hay llamadas simultáneas, datos reales y calendarios reales.
Dejé de buscar la solución en internet y empecé a construir la mía. Documenté cada error, cada fix, cada decisión. Este artículo es el resultado.
Copiar y pegar no es aprender. La diferencia entre demo y producción es brutal. Necesitas entender el sistema, no reproducirlo.
Errores de mentalidad
Los que cometí antes de tocar una sola línea de configuración.
Quise crear a Elio como una versión de mí misma: empático, flexible, creativo, con mi personalidad. El resultado fue un agente que inventaba cosas, no seguía el flujo y se perdía en conversaciones largas. Sonaba humano pero era impredecible.
Confundí el objetivo. Un agente de voz para empresa no necesita ser tú. Necesita ser consistente, preciso y acotado. La empatía sin estructura es caos.
Redefiní el objetivo de Elio: cualificar correctamente, transferir al departamento correcto y agendar citas. Nada más. Eliminé la empatía forzada y prioricé la consistencia.
Un agente de voz empresarial no es una persona. Es un sistema. Diseña para consistencia, no para creatividad.
Puse la temperatura a 0.3 pensando que así Elio sería más natural y conversacional. El resultado: inventaba precios que no existían, características técnicas incorrectas, servicios que netelip no ofrecía. Credibilidad comercial por los suelos.
No entendí que temperatura alta en un contexto empresarial no significa creatividad útil. Significa invención. Y en ventas, inventar destruye confianza.
Bajé la temperatura a 0.1 o 0 para respuestas críticas: precios, servicios, disponibilidad. La creatividad solo tiene sentido en el tono, nunca en los hechos.
Para datos empresariales, temperatura baja siempre. La creatividad del agente está en el tono, nunca en los hechos.
Metí toda la documentación de netelip en un solo documento enorme. Elio daba respuestas kilométricas, mezclaba información de productos distintos, tardaba en recuperar datos y a veces recuperaba la sección equivocada.
Más información no significa mejores respuestas. Un modelo de lenguaje con un documento enorme tiene más probabilidad de recuperar contexto incorrecto o de mezclar información de secciones distintas.
Dividí la KB en documentos pequeños y específicos por tema: servicios, precios, FAQs, integraciones. Apliqué chunking estratégico con 3 chunks y umbral de similitud 0.75. Instrucciones explícitas de cuándo usar cada KB.
Menos es más en knowledge base. Documentos pequeños y específicos superan siempre a un documento gigante.
Errores de prompt engineering
Los que hacían que Elio se comportara de forma impredecible.
Fui añadiendo instrucciones según surgían los problemas. El prompt era un desastre sin jerarquía: el modelo no tenía claro qué era prioritario, qué era contexto y qué eran reglas. El comportamiento era errático.
Un prompt sin arquitectura es como un contrato mal redactado: cada parte lo interpreta como quiere. GPT-4.1 sigue instrucciones al pie de la letra, pero si hay contradicciones o ambigüedad, elige mal.
Reestructuré el prompt con una arquitectura clara de 8 secciones: 1) Rol y objetivo, 2) Personalidad, 3) Contexto, 4) Instrucciones, 5) Herramientas, 6) Etapas, 7) Ejemplos, 8) Base de conocimiento. Orden y jerarquía desde el principio.
La estructura del prompt es tan importante como el contenido. Un prompt bien arquitectado multiplica la consistencia.
Descripciones genéricas como "transfer the call" o "book appointment". Elio no sabía cuándo transferir, a quién ni bajo qué condiciones. Transferencias incorrectas, reservas en momentos equivocados.
Asumí que el modelo "entendería" la intención. Los LLMs no adivinan. Necesitan instrucciones tan explícitas como si se las explicaras a alguien que nunca ha trabajado en tu empresa.
Reescribí cada descripción de función con criterios exactos: cuándo usarla, qué información necesita, qué hacer si falla, ejemplos de cuándo no usarla. Dynamic Routing Prompt con criterios claros.
Si una instrucción puede interpretarse de dos formas, el modelo elegirá la que no querías. Sé absurdamente específico.
La sección de ejemplos estaba vacía o con casos básicos. Elio no tenía referencia de cómo debía sonar una conversación real de principio a fin. El comportamiento era inconsistente entre llamadas.
Subestimé el poder de los ejemplos. Un modelo aprende mejor viendo casos reales que leyendo reglas abstractas.
Añadí 3 ejemplos completos: cliente existente buscando soporte, prospect en cualificación y persona equivocada que llama. Cada uno con flujo completo saludo-cierre.
Los ejemplos son tan importantes como las instrucciones. El modelo aprende el tono, el ritmo y la lógica de la conversación viéndola, no solo leyendo reglas.
El agente encontraba una respuesta de confirmación que funcionaba y la repetía en cada interacción. Los usuarios notaban la repetición. Sonaba robótico.
No instruí explícitamente sobre variar confirmaciones. El modelo optimiza por lo que funciona y lo repite.
Instrucción explícita: "Varía respuestas de confirmación: Genial, Perfecto, Estupendo, Entendido, Vale, De acuerdo. Nunca repitas la misma dos veces seguidas."
Los detalles pequeños marcan la diferencia entre un agente robótico y uno que suena humano. Lo obvio para ti no es obvio para el modelo.
Elio volvía a preguntar el nombre aunque el usuario ya lo había dicho. O pedía el email que ya había capturado 2 minutos antes. Experiencia frustrante y sensación de que el agente no escucha.
No instruí explícitamente sobre persistencia de información. El modelo no retiene datos entre turnos a menos que se le indique que los rastree.
Instrucciones claras: "Nunca pidas la misma información dos veces. Si el usuario menciona su nombre mientras responde otra pregunta, recuérdalo. Presta atención a información compartida de forma no explícita."
Lo que es sentido común para un humano no lo es para un LLM. Hay que explicitarlo todo, incluso las cosas más básicas.
Elio usaba el símbolo — en lugar de -, leía números como "3€" en vez de "tres euros", no sabía qué hacer con mensajes incompletos y no deletreaba emails correctamente.
No incluí instrucciones específicas para voz. Traté el prompt como si fuera para un chatbot de texto.
Integré reglas específicas de voz: mensajes incompletos responder con "uhm", nunca usar —, siempre -, símbolos como palabras, deletrear emails carácter por carácter, leer horas como "una de la tarde" no "13:00".
Voz no es chat. Las conversaciones habladas requieren instrucciones específicas para el medio. Son mundos distintos.
Errores de configuración en Retell AI
Los que hacían que el agente se comportara de forma impredecible sin razón aparente.
Hacía cambios, probaba llamadas, los cambios no se aplicaban. Pasé horas debugueando configuraciones que nunca habían entrado en vigor. Me volvía loca.
Los cambios en Retell AI no se publican automáticamente. Hay versiones Draft vs Published. Estaba probando siempre la versión antigua sin saberlo.
Hábito obligatorio: siempre pulsar Publish después de cada cambio. Verificar versión publicada. Esperar unos segundos antes de probar.
Si tus cambios no funcionan, probablemente no los estás probando. Verifica siempre qué versión está activa en producción.
Las variables tenían valores estáticos de prueba que me olvidé de conectar. Elio siempre ofrecía "miércoles a las 10" sin importar la disponibilidad real del calendario.
Configuré valores de prueba durante el desarrollo y nunca los reemplacé por la conexión real a webhook. Las variables solo son dinámicas si las conectas a una fuente dinámica.
Conecté todas las variables a los webhooks de N8N que consultan Cal.com en tiempo real. Variables que se actualizan en cada llamada con disponibilidad real.
Una variable dinámica con valor estático es una contradicción. Verifica siempre que se actualicen en tiempo real antes de lanzar.
La KB estaba en automático. Se activaba al consultar disponibilidad y en vez de usar las variables dinámicas correctas, el agente consultaba la KB, que no tenía horarios. Respuestas incorrectas e inconsistentes.
No había instrucciones de cuándo no usar la KB. En modo automático, el agente decide cuándo consultarla y a veces elige mal.
Desactivé la KB automática. Instrucción explícita: "No uses KB Retrieval para disponibilidad. Usa únicamente las variables dinámicas {{disponibilidad_mas_temprana}} y {{consultar_disponibilidad}}."
No confíes en que el agente decida bien cuándo usar cada recurso. Sé explícito sobre cuándo sí y cuándo no usar cada herramienta.
Las llamadas duraban más de 10 minutos. El contexto se saturaba. Elio empezaba a inventar: precios ficticios, servicios inexistentes, horarios imposibles.
No puse límite de duración. No estructuré el flujo para ser conciso. Cuando el contexto se satura, el modelo empieza a rellenar con invenciones.
Límite máximo de 10 minutos por llamada. Prompt optimizado para ir al grano. Flujo estructurado para cerrar conversaciones en 3-5 minutos.
Los modelos tienen límites de contexto reales. En producción, siempre pon límites de tiempo. Llamadas cortas y efectivas superan a largas y delirantes.
Errores con la integración del calendario
Los errores técnicos que hacían que las reservas fallaran o fueran incorrectas.
El prompt no especificaba cómo formatear las fechas. Elio decía "el próximo martes" y Cal.com no lo entendía. Las reservas fallaban.
Asumí que el modelo convertiría automáticamente las fechas relativas a formato absoluto. Cal.com requiere formato ISO estricto.
Instrucción explícita: "Convierte siempre a formato ISO absoluto: 2025-05-15T10:00:00. El tiempo debe ser siempre en el futuro. Nunca uses fechas relativas con la API."
Las APIs requieren formatos exactos. Explicita exactamente cómo formatear cada parámetro. No asumas que el modelo lo sabe.
Elio ofrecía horarios de horas anteriores en el mismo día o de días pasados. El usuario decía que sí y la reserva fallaba. Experiencia terrible.
Un LLM no sabe qué hora es a menos que se lo digas. No tiene conciencia temporal propia.
Instrucción: "Verifica que todos los horarios propuestos sean estrictamente futuros. Usa {{current_time_Europe/Madrid}} como referencia. Nunca ofrezcas horarios pasados."
Siempre incluye la hora actual como variable dinámica. Es la única referencia temporal que el agente tiene.
Elio ofrecía horarios sin consultar Cal.com. Los inventaba o usaba valores en caché. El usuario aceptaba y la reserva fallaba porque ese horario no existía.
Las variables dinámicas no estaban bien conectadas o el agente usaba la KB en lugar de las variables. Falta de instrucciones explícitas sobre el flujo de consulta.
Instrucción explícita: "Antes de ofrecer cualquier horario, usa siempre la variable {{disponibilidad_mas_temprana}}. Nunca inventes ni asumas disponibilidad."
Un agente que inventa disponibilidad es peor que no tener agente. La credibilidad se pierde en el primer error.
La función se ejecutaba pero Cal.com rechazaba las reservas. El agente no entendía por qué fallaba. Logs: "event type not found" o "no availability".
Tenía el ID del Event Type pero no verifiqué que estuviera activo, con disponibilidad configurada, zona horaria correcta y duración definida.
Checklist de verificación antes de conectar: Event Type activo, disponibilidad real configurada, zona horaria Europe/Madrid, duración definida, slots visibles en el calendario.
Tener el ID no basta. Verifica la configuración completa del recurso que usas antes de conectarlo al agente.
Reservas con desajuste de una o dos horas. Usuarios recibían confirmaciones con horarios incorrectos. Confianza por los suelos.
Cada servicio tiene su propia configuración de zona horaria. No lo consideré crítico hasta que empezaron a aparecer reservas desajustadas.
Unifiqué zona horaria en todo el stack: Retell AI → Europe/Madrid, Cal.com → Europe/Madrid, N8N → setZone('Europe/Madrid'), Prompt → "hora de Madrid", webhook → conversión explícita.
La zona horaria debe ser consistente en todo el stack. Un solo desajuste genera reservas erróneas. Compruébalo en cada capa.
Errores con Make y la arquitectura del sistema
Los que me costaron semanas de trabajo, el gran pivote a N8N y un staging que no existía.
Empecé con Make porque era la herramienta más mencionada en tutoriales. Los escenarios funcionaban en preproducción. Pero cuando unía Retell AI, Make, Google Calendar y los agentes supervisores de OpenAI, era imposible saber qué fallaba y dónde.
Make tiene una interfaz visual atractiva pero el debugging en producción es opaco. Cuando algo falla en un flujo complejo, los logs no te dicen lo suficiente para entender el problema real.
Borré todo. Empecé desde cero con N8N. N8N tiene logs detallados por nodo: puedes ver exactamente qué dato entra y qué dato sale en cada paso. El debugging pasó de ser imposible a ser sistemático.
La popularidad de una herramienta no es garantía de que sea la correcta para tu caso. Evalúa las capacidades de debugging antes de comprometerte.
Subí el sistema a producción. Las primeras llamadas fueron bien. A los 20 minutos, petó todo. Tuve que desconectarlo de urgencia. Había construido un castillo de arena.
No hice pruebas de carga real, no validé el comportamiento con múltiples llamadas simultáneas, no verifiqué la estabilidad del stack completo bajo condiciones reales. Salté de demo a producción sin etapa intermedia.
Introduje una fase de stress testing antes de producción: múltiples llamadas simultáneas, casos extremos, fallos simulados de Cal.com, timeouts. Solo subí a producción cuando el sistema aguantó sin degradarse.
Demo y producción son mundos distintos. Nunca saltes de preproducción a producción real sin una fase de stress testing.
Configuré webhooks entre Retell AI y N8N sin probarlos por separado. Cuando algo fallaba, no sabía si era Retell, N8N, Cal.com o el prompt. Horas perdidas debugueando todo a la vez.
Quería integrar todo rápido. No seguí la metodología de validar cada componente por separado antes de unirlos.
Metodología obligatoria: 1) Probar webhook desde navegador, 2) Listen for test event en N8N, 3) Verificar workflow activado, 4) Nodo Respond to Webhook conectado, 5) Solo entonces conectar Retell AI.
Prueba cada componente de forma independiente antes de integrar. Cuando algo falla en un sistema integrado, sabrás exactamente dónde está el problema.
Cuando Cal.com rechazaba una reserva (horario ocupado, error técnico, formato incorrecto), el agente se quedaba en silencio o decía algo genérico. La conversación se rompía sin solución.
Solo diseñé el flujo feliz. No contemplé qué hacer cuando las cosas fallan, y las cosas siempre fallan.
Manejo completo de escenarios: éxito (confirma con fecha y hora exacta), horario ocupado ("ese horario acaba de reservarse, déjame consultar otros"), error técnico ("problema técnico, te envío confirmación por email").
Las cosas fallan siempre. Define qué hace el agente en cada escenario de error. El manejo de errores es tan importante como el flujo principal.
Cualquier prueba que hacía era sobre el sistema real. Cuando probaba el flujo de reservas, Cal.com enviaba la confirmación por email al contacto real y Elio confirmaba por voz al mismo tiempo. Algunos usuarios recibían dos confirmaciones, otras veces contradictorias: el agente decía una hora por voz y el email de Cal.com confirmaba otra.
No existía un entorno de pruebas separado. El mismo agente, el mismo calendario y los mismos números virtuales atendían pruebas y llamadas reales a la vez. Romper cosas tenía consecuencias reales para usuarios reales.
Creé un entorno de staging completo e independiente: un Event Type de staging en Cal.com exclusivo para pruebas con notificaciones desactivadas, un número virtual de netelip dedicado solo a testing y un agente separado en Retell AI. Producción y staging nunca comparten recursos.
Un entorno de staging no es un lujo. Es lo que separa iterar con miedo de iterar con control. Producción y staging nunca comparten recursos.
Errores de testing y metodología
Los que me hicieron perder tiempo y me impedían saber qué estaba fallando realmente.
Cambiaba prompt, configuración y variables al mismo tiempo. Algo mejoraba o empeoraba y no sabía qué cambio había causado la diferencia. Imposible saber qué funcionaba.
Ansiedad por arreglar rápido. Pensaba que más cambios significaba solución más rápida. Era lo contrario.
Metodología de cambios incrementales: un cambio a la vez, probar, validar, documentar, siguiente. Si funciona, documenta exactamente qué funcionó. Si falla, deshaz solo ese cambio.
Lento es rápido. Un cambio a la vez y sabes exactamente qué funciona. Múltiples cambios simultáneos es caos puro.
Hacía cambios sin saber exactamente qué estaba fallando. Probaba a ciegas. Perdía tiempo con cambios que no arreglaban el problema real porque no lo había identificado.
No sabía dónde mirar los logs en Retell AI. Me parecían confusos. Tenía prisa por arreglar rápido.
Metodología obligatoria: siempre revisar logs y transcripciones antes de cambiar nada. Identificar el error exacto. Solo entonces hacer el cambio dirigido.
No puedes arreglar lo que no entiendes. Los logs te dicen exactamente qué pasa. Léelos siempre antes de tocar nada.
Probaba el agendamiento sin verificar que hubiera disponibilidad real en Cal.com. La función fallaba y yo pensaba que era un error del sistema. Pasaba horas debugueando algo que tenía solución en 30 segundos.
Asumía que el calendario tenía disponibilidad porque lo había configurado hacía días. Los bloques caducaban, las horas pasaban, los slots se llenaban con otras reservas.
Checklist de prueba antes de cada sesión de testing: abrir Cal.com, verificar que el Event Type tiene slots disponibles en las próximas horas, confirmar que la integración está activa. 30 segundos que ahorran horas.
Antes de debuguear el sistema, verifica que el entorno de prueba está en condiciones. Muchos errores aparentes son condiciones de prueba incorrectas.
Elio hoy, después de los 27 errores
Números reales. Sin maquillaje.