Skip to main content

​
¿Qué son los Flujos Durante Llamada?

Un flujo durante llamada es un flujo que el agente puede ejecutar mientras habla con el usuario, como si fuera una herramienta. Donde una integración llama a un solo endpoint, un flujo durante llamada ejecuta un flujo multi-paso completo — y puede devolver el resultado a la conversación. Úsalo cuando una sola llamada a la API no es suficiente:
  • Buscar un cliente, luego revisar sus pedidos abiertos, y después formatear el resultado combinado
  • Consultar varios sistemas y combinar las respuestas
  • Hacer una reserva que requiere varias APIs en secuencia
  • Ramificar según una respuesta antes de devolver los datos al agente
Los flujos durante llamada se ejecutan durante la conversación. Compáralos con los flujos pre-llamada (antes de que el agente salude) y los flujos post-llamada (después de que la llamada termina).

​
Cómo funciona

1

El agente decide actuar

En mitad de la conversación, el agente reconoce que necesita hacer algo — consultar disponibilidad, buscar una cuenta — según la descripción de función que escribiste.
2

Se ejecuta el flujo

El agente extrae los parámetros de la conversación y se dispara el trigger Llamada a función, ejecutando el flujo.
3

El agente continúa

El agente espera el resultado y lo usa para seguir hablando.

​
Crear un Flujo Durante Llamada

1

Crea un flujo

Desde la sección Flujos, crea un nuevo flujo (desde cero o a partir de una plantilla). Consulta Crear Flujos.
2

Selecciona el trigger Llamada a función

Elige la pieza de Diga y selecciona el trigger Llamada a función. El agente tratará este flujo como una herramienta que puede invocar.
3

Configura el trigger

Define cómo y cuándo usa el agente el flujo:
  • Descripción de la función — cuándo debe llamarlo el agente, en lenguaje natural
  • Parámetros — qué debe extraer el agente de la conversación (y si cada uno lo extrae la IA o se toma de una variable dinámica)
  • Confirmación de usuario — si el agente confirma antes de ejecutar
Consulta La Pieza de Diga para la referencia completa de campos.
4

Añade tus acciones

Añade los pasos que realiza el flujo — peticiones HTTP, consultas a bases de datos, otras piezas — usando los parámetros que extrae el agente.
5

Devuelve el resultado

Termina el flujo con la acción Devolver respuesta de Diga para que el agente reciba los datos y pueda continuar la conversación.
El flujo debe terminar con Devolver respuesta y responder en menos de 60 segundos. De lo contrario el agente recibe un error y continúa sin los datos.
6

Publica y habilita

Publica el flujo y asegúrate de que esté habilitado. Luego asígnalo a un agente (ver más abajo).

​
Parámetros

Los parámetros son los datos que el agente pasa al flujo cuando se ejecuta. Para cada parámetro defines un nombre, un tipo de dato, si es obligatorio y — lo importante — un Origen del valor que decide de dónde sale su valor:
  • Extraído por la IA (por defecto): el agente toma el valor de la conversación, usando la descripción del parámetro para saber qué buscar.
  • Variable dinámica: el valor viene de una variable dinámica de la llamada en lugar de ser extraído.

​
Rellenar parámetros desde variables dinámicas

A menudo ya tienes un valor — pasado por la API, definido como valor por defecto del agente, o producido por un flujo pre-llamada — y no quieres que el agente vuelva a pedirlo (ni que se arriesgue a equivocarse). Para esos parámetros, configura el Origen del valor como Variable dinámica.

​
Cómo configurarlo

1

Añade o edita un parámetro

En el trigger Llamada a función, abre el parámetro que quieres rellenar automáticamente.
2

Cambia Origen del valor a Variable dinámica

Cambia Origen del valor de Extraído por la IA a Variable dinámica. El campo de descripción se sustituye por un campo Nombre de la variable dinámica.
3

Indica el nombre de la variable

Escribe el nombre de la variable sin llaves — por ejemplo id_reserva, no {{id_reserva}}.

​
Qué ocurre durante la llamada

  • El parámetro se quita de lo que el agente tiene que deducir — nunca se le pide y no puede rellenarlo mal.
  • Cuando el flujo se ejecuta, Diga rellena ese parámetro con el valor actual de la variable dinámica correspondiente en la llamada y lo envía en el payload del flujo.
  • Los parámetros que dejas como Extraído por la IA siguen funcionando igual, junto a los dinámicos.
La variable debe existir realmente en la llamada. Asegúrate de que la proporcione la API, un valor por defecto del agente o un flujo pre-llamada — si falta, el parámetro se envía vacío.

​
Ejemplo

Un flujo de “Modificar reserva” donde el ID de la reserva ya se conoce por una búsqueda pre-llamada, así que solo el resto queda en manos del agente: El contacto simplemente dice “Quiero cancelar mi reserva.” El agente extrae accion = cancelar, Diga inyecta id_reserva desde la variable dinámica, y el flujo recibe los tres valores.
Los parámetros que rellenas así también aparecen en el panel de variables dinámicas del agente, donde puedes darles un valor de prueba para probar el flujo antes de ponerlo en producción. Consulta Variables Dinámicas.

​
Asignar Flujos Durante Llamada a un Agente

Abre el agente y ve a su sección Flujos. Añade ahí el flujo durante llamada. Cada flujo muestra una etiqueta Durante la llamada.Puedes asignar múltiples flujos durante llamada al mismo agente — cada uno se convierte en una herramienta que el agente puede elegir usar, según la descripción de la función.
Como el resto de flujos, los flujos durante llamada se asignan por versión de agente. El flujo debe estar publicado y habilitado para que se ejecute.

​
Cuando el llamante interrumpe un flujo en ejecución

Los llamantes reales no esperan educadamente: añaden detalles o cambian de opinión mientras un flujo todavía se está ejecutando. Diga lo gestiona por ti:
  • La ejecución nunca se cancela. Una vez disparado, el flujo se ejecuta hasta el final: cancelarlo en local no desharía una cita que ya se está creando en tus sistemas.
  • El agente se mantiene informado. Se le avisa al instante de que el flujo sigue en marcha (para que no lo vuelva a llamar) y recibe el resultado real en cuanto termina, tanto si es un éxito como un fallo.
  • El agente reconoce lo que ya ha pasado. Si el llamante cambió de opinión a mitad de ejecución, el agente dice en voz alta lo que ya se hizo antes de ajustar, en lugar de fingir que no pasó nada o duplicar la acción en silencio.
  • Una petición corregida se ejecuta como una nueva. Si el llamante corrige un detalle mientras el flujo se ejecuta (“mejor a las 8”), el agente vuelve a ejecutar el flujo con los valores corregidos. Nunca da por hecho un cambio si no lo ha ejecutado de verdad.
  • El agente termina su frase primero. Un resultado que llega mientras el agente está hablando se entrega en la siguiente pausa, nunca cortándole a mitad de frase.
Este comportamiento viene de serie: no necesitas pedirlo en el prompt. Lo que tú controlas es qué puede ofrecer el agente honestamente a continuación:
Respalda con un flujo cada promesa de tu prompt. El comportamiento integrado nunca afirma una acción que el agente no puede realizar: si el llamante quiere cambiar una cita y el agente solo tiene un flujo de crear, dirá con claridad que la cita anterior sigue existiendo y habrá que gestionarla, no fingirá cancelarla. Si reprogramar o cancelar importa en tu caso de uso, crea también esos flujos y asígnalos. Si decides no hacerlo, indica en el prompt qué debe hacer el agente en su lugar (por ejemplo, “si el llamante quiere cambiar una cita, anótalo para que lo gestione el equipo”).
Redacta el mensaje de Return Response como algo que el agente pueda decir en voz alta, en el idioma de tus llamantes. El agente construye su respuesta a partir de él: “Cita creada para el 25 de agosto a las 10:00” produce una respuesta mucho más natural que un estado técnico en inglés.

​
Si el flujo falla mientras el llamante habla

Lo que el agente le dice al llamante depende de lo que demuestre el fallo:
  • La petición fue rechazada (el endpoint respondió con un error de cliente como 400 o 404, así que nunca llegó a ejecutarse): el agente sabe que no se guardó nada, lo dice, y puede volver a intentarlo con los datos corregidos.
  • El resultado es desconocido (el flujo agotó el tiempo de espera, falló con un error de servidor como 500, o se cortó la conexión): el flujo puede haberse completado antes del error, así que el agente no afirma ni que funcionó ni que falló. Le dice al llamante que no ha podido confirmar la acción y que se revisará, y no vuelve a ejecutar el flujo, porque repetirlo podría crear un duplicado.
Si tu flujo detecta un problema, termínalo con un Return Response que lo diga con palabras sencillas en lugar de dejar que falle. Un error o un tiempo de espera agotado dejan al agente sin saber si ha pasado algo; una respuesta explícita le permite contarle al llamante exactamente qué ocurre.

​
Casos de uso comunes

El agente pregunta una fecha, ejecuta el flujo para consultar tu calendario y lee los horarios disponibles.
Obtén los datos y la actividad reciente de un cliente de uno o varios sistemas, combínalos y devuelve un resumen claro que el agente pueda usar.
Ejecuta en secuencia las distintas llamadas a la API que requiere una reserva, y luego confirma el resultado al usuario.
Crea un ticket en tu sistema, y luego confirma al usuario que se ha registrado.

​
Siguientes Pasos

La pieza de Diga

Referencia completa del trigger Llamada a función y la acción Devolver respuesta.

Flujos pre-llamada

Prepara y personaliza cada llamada antes de que el agente salude.

Integraciones

Compara los flujos durante llamada con las integraciones de un solo endpoint.

Asignar a agentes

Conecta tus flujos con agentes para que se ejecuten.