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, 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ífico 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.