Cómo destruí mi propio agente de voz con IA (y lo reconstruí mejor)

Qué hice mal

Empecé con Google Calendar pensando que sería más fácil porque es más conocido.

Monté toda la automatización en Make porque "es lo que usa todo el mundo".

Cuando algo fallaba, no podía ver DÓNDE ni POR QUÉ.

• Google Calendar no me devolvía los slots disponibles correctamente.
• Make tiene logs confusos y visualización poco clara.
• No podía seguir el flujo cuando las cosas se rompían.

Por qué falló

Cada herramienta tiene su propia lógica y documentación. Estaba perdiendo tiempo intentando entender cómo Make procesaba las respuestas de Google Calendar. Era un stack imposible de debuguear cuando todo explotó.

Cómo lo arreglé

Lo tiré TODO a la basura.

Migré a Cal.com:

• Integración nativa con Retell AI, Google Calendar y HubSpot.
• API más directa.
• Documentación clara.

Migré a n8n:

• Visualización clara de errores.
• Puedo ver paso a paso qué está pasando en cada nodo.

Empecé desde cero con un stack más limpio.

Ahora tengo 2 escenarios en n8n:

Flujo 1 — Llamadas entrantes + variables dinámicas:

1. Webhook recibe llamadas entrantes.
2. Edit Fields configura variables de Cal.com.
3. Obtener disponibilidad en Cal.com (GET API).
4. Transformar disponibilidad con OpenAI GPT-4.1 (Modelo 1).
5. Disponibilidad más temprana con OpenAI GPT-4.1 (Modelo 2).
6. Respuesta webhook con variables dinámicas en JSON.

Flujo 2 — Post Call Analysis + email:

1. Webhook informe fin de llamada de Retell AI.
2. call_analyzed (análisis con Retell AI).
3. Append row en Google Sheets.
4. Send email con HTML personalizado.

Lección aprendida

• Elige herramientas que puedas debuguear cuando (no "si", sino "cuando") algo falle.
• La popularidad de una herramienta NO garantiza que sea la mejor para tu caso de uso.

Qué hice mal

Hacía cambios en el prompt de Retell AI. Probaba llamadas. Los cambios NO se aplicaban.

Me volvía loca pensando: "¿POR QUÉ CARAJO NO FUNCIONA?"

Por qué falló

En Retell AI, los cambios NO se publican automáticamente. Hay versiones "Draft" vs "Published". Estaba probando la versión vieja sin darme cuenta.

Perdí 3 días probando cambios que nunca se aplicaron.

Tenía la versión 155 en Draft, pero en producción seguía corriendo la versión 148.

Cómo lo arreglé

• SIEMPRE hacer clic en "Publish" después de cada cambio.
• Verificar que la versión publicada es la correcta en el Agent ID.
• Esperar unos segundos después de publicar antes de probar.

Lección aprendida

Lee la maldita documentación. "Que no existe en ninguna parte". En serio.

Ese botón me costó 3 días de locura y lágrimas.

No asumas que las cosas funcionan como en otras plataformas.

Qué hice mal

No fui específica en las instrucciones para consultar disponibilidad y reservar citas.

Descripciones genéricas: "Book appointment" sin detalles sobre formato de fecha, zona horaria o parámetros exactos.

Configuré la búsqueda de disponibilidad desde Retell AI en vez de n8n.

Resultado: reservas que fallaban por formato de fecha incorrecto y horarios que no se actualizaban.

Por qué falló

• Di instrucciones demasiado genéricas sin adaptar a mi caso específico.
• Pensé que el LLM "entendería" qué hacer sin ser específica.
• No especifiqué detalles críticos: formato de fecha absoluta, zona horaria, parámetros exactos.
• Las instrucciones eran ambiguas: "consulta disponibilidad" sin decir CÓMO.

Cómo lo arreglé

Instrucciones SÚPER específicas en la función reservar_cal:

Cuando el usuario acuerde un horario disponible, resérvalo en el calendario.

El parámetro de tiempo debe ser una fecha absoluta completa, como:
"Jueves, 2025 Mayo 15/05/2025 10 AM"

Incluso si el usuario pide una fecha relativa como "el próximo martes",
conviértela a fecha absoluta.

- El tiempo siempre debe estar EN EL FUTURO.
- Tiempo actual: {{current_time_Europe/Madrid}} (Hora de Madrid).
- Parámetro de zona horaria: "Europe/Madrid".
- Parámetro de notas: resumen de una oración de la conversación.
- Parámetro de nombre: {{user_name}}.

Moví la consulta de disponibilidad a n8n:

• Webhook en n8n consulta Cal.com API en tiempo real cada vez que entra una llamada.
• Modelo 1 (OpenAI GPT-4.1): transforma disponibilidad completa de 6 días en lenguaje natural.
• Modelo 2 (OpenAI GPT-4.1): extrae los 2 primeros horarios disponibles en español natural.

Las variables se actualizan dinámicamente en cada llamada con formato JSON:

{
  "call_inbound": {
    "override_agent_id": "agent_XXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "dynamic_variables": {
      "disponibilidad_mas_temprana": "martes dieciocho a las diez de la mañana o por la tarde a las cuatro de la tarde",
      "consultar_disponibilidad": "Disponibilidad completa de 6 días en lenguaje natural"
    }
  }
}

Lección aprendida

• Los LLMs no adivinan. Sé tan específica como si le explicaras a alguien que nunca ha trabajado en tu empresa.
• Cada detalle cuenta: formato de fecha, zona horaria, conversión de fechas relativas a absolutas.
• "Dinámico" significa que SE ACTUALIZA EN TIEMPO REAL con webhooks, no valores hardcodeados.

Qué hice mal

• No puse límite de duración en las llamadas.
• Las llamadas duraban más de 10 minutos.
• Se agotaban los tokens disponibles de GPT-4.1.
• Elio empezaba a alucinar precios inventados, horarios falsos, información que no existía.
• Configuré mal el prompt: metí todo el conocimiento en un solo prompt de 4.000 tokens pensando que más contexto = mejor agente.

Por qué falló

No estructuré el flujo para ser conciso. El agente se enrollaba demasiado o entraba en bucles. GPT-4.1 tiene límites de contexto que yo no respeté.

Lo hice demasiado empático. Intenté duplicarme con mi personalidad, mi forma de vender, mi forma de hablar. Elio era como yo: hablaba por los codos, era divertido, neurodivergente, pero sin sentido común. Alucinaba demasiado y de vez en cuando te cantaba un fandango.

Error: un agente de voz para tu empresa tiene que ser consistente, persistente, y no darle posibilidad de errores.

Cómo lo arreglé

Configuré límite máximo de 10 minutos por llamada (max_call_duration_ms: 601000).

Optimicé el prompt para ser más directo:

• "Haz solo una pregunta a la vez y espera respuesta".
• "Mantén las interacciones breves con oraciones cortas".
• "Máximo 30 segundos por respuesta".
• Eliminé redundancias y divagaciones del flujo.

Estructuré etapas claras:

1. Saludo y cualificación.
2. Routing (cliente → transferencia | no cliente → knowledge base).
3. Agendamiento (si no es cliente).
4. Cierre final.

Dividí el conocimiento en 2 Knowledge Bases separadas en Retell AI:

• Knowledge Base 1: servicios de netelip.
• Knowledge Base 2: seguridad de los agentes (para evitar que algún tontorrón de los que salen en YouTube me lo intente hackear).

Lección aprendida

• Los agentes de voz NO son chatbots.
• En voz, cada segundo cuenta. Sé breve o muere.
• No repliques tu personalidad en un agente. Crea un sistema que funcione de forma predecible.

Qué hice mal

Cuando Google Calendar rechazaba una reserva (horario ocupado o conflicto), Elio se quedaba en silencio.

Solo tenía programado el "happy path": cuando todo sale bien.

Error en logs: "User either already has booking at this time or is not available".

Y yo sin saber qué hacer.

Por qué falló

• El prompt no tenía instrucciones sobre QUÉ HACER cuando las funciones fallan.
• No manejaba errores de API.
• No había plan B para cuando las cosas se rompían.

Cómo lo arreglé

Agregué una sección completa en el prompt con manejo de errores en 3 escenarios:

**PASO 5: Manejo de respuesta de reservar_cal**

**A) Si retorna ÉXITO:**
- Di: "Listo, {{user_name}}. Tu cita está confirmada para el [fecha y hora exacta], hora de Madrid. Recibirás un correo de confirmación".

**B) Si retorna ERROR de horario ocupado:**
- Di: "Disculpa, {{user_name}}, ese horario acaba de ser reservado.
  Déjame consultar otros horarios disponibles…".
- Consulta {{consultar_disponibilidad}} nuevamente.
- Ofrece 2 nuevas opciones.

**C) Si retorna ERROR TÉCNICO:**
- Di: "Disculpa, {{user_name}}, tenemos un problema técnico.
  Por favor envía un correo a citas@netelip.com".

Lección aprendida

• En producción, TODO falla eventualmente.
• Planifica el "sad path", no solo el "happy path".
• Un agente sin manejo de errores es un agente que te dejará en ridículo frente a tus clientes.