Orquestación de agentes
Last updated
Last updated
La orquestación es la capacidad de descomponer un escenario único y completo en la plataforma en varios agentes.
Un proyecto representa un escenario, y los agentes dentro del proyecto son partes del escenario que pueden interconectarse.
Los proyectos tienen canales de proyectos. Cada canal tiene un agente predeterminado que recibe los mensajes entrantes en este canal.
Un agente puede ser agente por defecto en varios canales.
Proyecto multilingüe: llega un mensaje de un usuario, el agente principal determina el idioma del mensaje del usuario y, a continuación, en función del idioma determinado, se produce una transición a otro agente en el idioma requerido utilizando la ranura del agente Switch.
De este modo, es más fácil y cómodo mantener agentes en distintos idiomas: los diseñadores de diálogos que hablan lenguas diferentes pueden editar y volver a entrenar a sus respectivos agentes.
Proyecto de contratación: el proyecto contiene varios agentes con diferentes escenarios de entrevistas para diferentes vacantes, y hay un canal del proyecto a través del cual se envían los correos de WhatsApp. Cuando llega un mailing al webhook de uno de los slots de Notificación ubicados en estos agentes, la plataforma determina a través del webhook qué escenario del agente debe iniciarse.
De este modo, un escenario grande con muchas franjas horarias de Notificación puede dividirse en varios agentes, lo que facilita la edición de cada escenario por separado.
Proyecto con entrevista y NLU. El proyecto contiene un agente con un escenario de encuesta con botones y un agente con NLU. Si el usuario hace una pregunta en lugar de pulsar un botón, el chat cambia al agente con NLU utilizando la ranura Cambiar agente.
De este modo, el escenario se vuelve más compacto y el agente NLU puede seguir entrenándose sin involucrar el escenario de la entrevista.
Un nuevo chat al abrirse puede ser asignado a uno u otro agente de la siguiente manera:
Un mensaje entrante de un usuario llegó al canal, y el chat se abrió en el agente A, ya que el agente A es el agente por defecto del canal.
Ha llegado un correo a un webhook específico de la ranura de Notificación, y el chat se inicia en el agente donde se encuentra la ranura de Notificación correspondiente con este webhook.
El diálogo se fija a un agente específico, y la comunicación se produce sólo en este agente hasta que el diálogo se transfiere a través de la ranura del agente Switch o se produce un evento (solicitud entrante, envío a través de la ranura de notificación, temporizador).
Al transferir un chat entre agentes, no se crea un nuevo chat, sino que se crea un nuevo diálogo con el nuevo agente y se cierra el diálogo con el agente anterior. El contexto del chat se conserva íntegramente cuando se transfiere entre agentes.Un chat puede transferirse a otro agente en dos casos:
A través de la ranura del agente de conmutación.
La ranura transfiere el chat al agente seleccionado en el campo Agente;
b. Al transferir un chat a otro agente, el diálogo en el nuevo agente comienza desde el principio del escenario;
c. Al cambiar de agente, se cierra el diálogo con el agente anterior y se abre el diálogo con el nuevo;
d. Al abrir un diálogo con el nuevo agente, la primera/siguiente ranura de espera (Inicio, Esperar reacción, Llenado de ranura, Menú de botones) de la sucursal acepta automáticamente la variable client_message del agente anterior.
Por evento:
Un chat puede ser transferido a otro agente durante varios eventos, dependiendo de:
el tipo de evento (solicitud entrante, envío por ranura de notificación, temporizador)
su urgencia (si se trata de una solicitud entrante o de un envío)
los ajustes en la ranura del agente de conmutación
b. Solicitud/envío entrante urgente (el parámetro is_urgent en la solicitud/envío entrante es true):
i. Estos eventos se activan en cualquier caso, y al activarse, el chat siempre cambia al agente en el que se encuentra la ranura correspondiente.
Ejemplo: el agente A transfiere el chat al agente B, luego llega una solicitud entrante urgente o un correo al agente A, y el chat vuelve al agente A.
c. Solicitud/envío entrante no urgente (el parámetro is_urgent en la solicitud/envío entrante es falso, o no se especifica, en cuyo caso se utiliza el valor falso por defecto):
i. Este tipo de evento (diferido/no urgente) se activa del siguiente modo: el evento entra en la cola de espera y espera hasta que finaliza el diálogo, sólo entonces se activa el evento y el chat pasa al agente en el que se encuentra la ranura correspondiente.
ii. Estos eventos se activan (independientemente del agente en el que se encuentre el chat) si, al transferir el chat de un agente a otro a través de la ranura Cambiar agente, se desactivó la opción de reinicio de cola.
iii. Si la opción de reinicio de cola estaba activada, y:
la Solicitud entrante/envío diferido llegó al agente A antes de que el chat se transfiriera del agente A al agente B utilizando la ranura Cambiar agente: entonces la cola de eventos del agente A se borra, y la Solicitud entrante/envío diferido no se activa
la Solicitud entrante/envío diferido llegó al agente A después de que el chat se transfiriera del agente A al agente B utilizando la ranura Cambiar agente: entonces la cola de eventos del agente A no se borra, y la Solicitud entrante/envío diferido se activa después de que se cierre el diálogo.
Ejemplo A: se produce una comunicación en el agente A, a continuación el agente A transfiere el chat al agente B, con la opción de reinicio de cola desactivada en la ranura Cambiar de agente. A continuación, llega al agente A una solicitud entrante no urgente o un correo y entra en la cola de espera. El diálogo en el agente B se cierra debido a un tiempo de espera y, a continuación, se activa la solicitud entrante o el envío y el chat vuelve al agente A.
Ejemplo B: se produce una comunicación en el agente A, a continuación el agente A transfiere el chat al agente B, con la opción de reinicio de cola activada en la ranura Cambiar de agente. A continuación, llega al agente A una solicitud entrante no urgente o un correo y entra en la cola de espera. El diálogo en el agente B se cierra debido a un tiempo de espera y, a continuación, se activa la solicitud entrante o el envío de correo (ya que la solicitud entrante o el envío de correo llegaron después de que la cola se despejara mediante la ranura Cambiar agente), y el chat vuelve al agente A.
Ejemplo C: se produce una comunicación en el agente A, llega una solicitud entrante no urgente o un correo al agente B y entra en la cola de espera. Entonces el agente A transfiere el chat al agente B, con la opción de reinicio de cola activada en la ranura Cambiar de agente. La cola de eventos se borra. El diálogo en el agente A se cierra debido a un tiempo de espera, la Solicitud entrante o el correo no se activan.
d. Temporizadores:
i. Un temporizador sólo puede establecerse en el agente en el que se encuentra actualmente el chat.
ii. Los temporizadores se activan (independientemente del agente en el que se encuentre el chat) sólo si, al transferir el chat a través de la ranura del agente Switch, se desactivó la opción de reinicio de la cola.
iii. Si se ha activado la opción de reinicio de la cola, los temporizadores no se activan.
Ejemplo A: el chat está en el agente A. Se establece un temporizador en el agente A y entra en la cola de ejecución (no puede establecerse en ningún otro lugar ya que el chat está en el agente A). El agente A transfiere el chat al agente B, con la opción de reinicio de cola desactivada en la ranura Cambiar agente. El agente B se comunica en el chat. El temporizador en el agente A se dispara, y el chat vuelve inmediatamente al agente A.
Ejemplo B: el chat está en el agente A. Se establece un temporizador en el agente A y entra en la cola de ejecución (no puede establecerse en ningún otro lugar ya que el chat está en el agente A). El agente A transfiere el chat al agente B, con la opción de reinicio de cola activada en el slot Cambiar agente. El agente B se comunica en el chat. El temporizador no se activa porque la cola se ha restablecido.