Contenido
- Cómo se arman los pasos en un escenario
- Dashboard de trabajo
- Cómo el agente recorre el escenario
- Cómo elegir la estructura del escenario
El escenario es la lógica de comportamiento del agente definida de antemano y compuesta por pasos enlazados entre sí. Cómo está estructurado un paso individual como bloque de construcción se explica en la sección «Pasos del escenario»; aquí veremos cómo se compone un escenario a partir de los pasos, cómo avanza el agente por él y cómo elegir su estructura según la tarea.
Cómo se arman los pasos en un escenario
Principio clave: el escenario lo hace avanzar el propio agente. Aunque en el mapa esté dibujada una flecha del paso A al paso B, no es una ejecución automática: el agente ve los pasos disponibles en ese momento y las indicaciones, y decide por sí mismo invocar el siguiente. Gracias a esto, el agente no es un «robot sobre rieles»: si el cliente aclara algo en medio del escenario, el agente puede responder a su pregunta y luego volver al escenario.
Los pasos se enlazan entre sí mediante acciones:
- «Ir a otro paso»: enlace inmediato; tras el paso actual, el agente recibe la tarea de pasar al siguiente. La transición puede ser directa (siempre el mismo paso siguiente) o ramificada (distintos pasos según cuál de las opciones de valor predefinidas se haya elegido en el campo del paso).
- «Ejecución diferida del paso»: enlace en el tiempo; el sistema arrancará por sí mismo el paso indicado tras el intervalo definido (ver la sección «Acciones diferidas»).
- «Solicitar ayuda al asesor»: el diálogo pasa a una persona y, tras su trabajo, el control puede volver al agente en un paso determinado.
Aquí es importante distinguir entre lo que el agente ve y lo que puede hacer. La estructura del escenario —los pasos y las transiciones entre ellos— el agente en general la ve: esto lo ayuda a entender cómo está organizada la conversación y a dónde puede llevar. Pero no puede ir a cualquier sitio: invocar un paso o abrirlo por transición solo lo puede hacer entre los que están disponibles en ese momento, y eso lo determinan las casillas de visibilidad y las transiciones configuradas. En detalle sobre la disponibilidad, en la sección «El agente solo dispone de los pasos permitidos en ese momento».
Dashboard de trabajo
Mientras el agente recorre el escenario, el sistema le muestra el dashboard de trabajo: un resumen del estado actual: qué se ha recopilado ya, qué falta, hacia qué paso avanzar. El dashboard se actualiza en cada turno e influye mucho en las acciones del agente. Su composición se describe en detalle en la sección «Dashboard de trabajo».
Para el autor del escenario hay aquí un matiz importante: el dashboard ya dirige al agente, por eso no hace falta duplicar directivas estrictas por todas partes. Es mejor guiar al agente con suavidad —mediante las descripciones de los pasos y el prompt— y dejarle espacio para razonar. A veces conviene permitirle explícitamente ser flexible: por ejemplo, «si el cliente pregunta algo, respóndele antes de volver al escenario».
Cómo el agente recorre el escenario
Este es el núcleo del diseño del escenario: aquello para lo que los pasos existen en primer lugar.
Las capacidades del agente las dan los pasos, no el prompt
El agente que trabaja en el chat, por defecto, sabe comunicarse por sí mismo, y bastante bien: llevar el diálogo, responder preguntas, buscar materiales en la base de conocimientos, seleccionar productos. Pero todo eso sigue siendo conversación. Si las tareas del agente están descritas solo en el prompt principal, intentará resolverlas literalmente de palabra: preguntar algo, prometer algo; por ejemplo, prometer sin fin conectar con un asesor y al final no conectar, porque sencillamente no tiene con qué ejecutar la acción en el sistema.
Las capacidades reales solo le aparecen al agente junto con los pasos del escenario y las acciones dentro de ellos. El paso es una herramienta que el agente puede (y debe) invocar para hacer trabajo útil: no «prometer traspasar al asesor», sino traspasar de verdad. Por eso, en el prompt principal basta con destacar qué funciones tiene el agente y qué paso invocar para cada cosa. Mientras que las instrucciones precisas y detalladas de «cómo hacerlo exactamente» deben vivir en los propios pasos: el agente las recibe poco a poco, a medida que avanza por el escenario, y no las mantiene todas en la cabeza a la vez.
Con qué dirige el sistema al agente
Mientras el agente recorre el escenario, el sistema le plantea tareas y se las muestra en el dashboard de trabajo (ver la sección «Dashboard de trabajo» más arriba). Estas son las palancas con las que tú, como autor, controlas su comportamiento. Los tipos principales de tareas:
- Instrucción directa: una indicación breve de hacer algo ahora mismo, definida mediante la acción «Agregar instrucción».
- Recopilación de datos de un paso bloqueado: mientras al paso le falten campos obligatorios (o no se haya superado la comprobación manual de condiciones mediante la acción «Bloquear ejecución del paso»), el sistema mantiene ante el agente la tarea de recopilar lo que falta.
- Direccionamiento al siguiente paso: la indicación de avanzar, definida mediante la acción «Ir a otro paso». Esta transición se puede hacer «silenciosa»: entonces el agente no puede escribirle al cliente entre pasos y debe seguir en silencio la ruta indicada, lo que mejora notablemente la estabilidad del comportamiento en los tramos críticos.
- Contexto persistente: la acción «Actualizar contexto del escenario» añade al dashboard una indicación de fondo que influye mucho en cómo el agente sigue el escenario a continuación.
- Borrado de tareas: la acción «Borrar tareas del agente» retira a tiempo las tareas acumuladas, para que el agente cambie limpiamente entre las distintas ramas del escenario y no arrastre objetivos antiguos.
Cómo se encadenan los pasos en un recorrido del escenario
En el curso normal de un diálogo esto se ve así. El agente arranca cuando el cliente escribe por primera vez en un diálogo nuevo. Si en el escenario hay un paso inicial (interruptor «Paso inicial»), el agente recibe de inmediato en el dashboard la tarea de pasar a él.
Después importa la mecánica del «toque». El agente siempre puede invocar un paso —«tocarlo», es decir, empezar a trabajar con él—, aunque el paso tenga campos obligatorios. Pero si faltan datos (o hay un bloqueo manual), la tarea de direccionamiento se convierte en una tarea más importante: recopilar lo que falta. Esa tarea no desaparecerá del dashboard hasta que el agente traiga todos los campos necesarios.
En cuanto los ha recopilado e invoca el paso, se ejecutan las acciones del paso, y aquí volvemos a dirigir al agente: le damos una instrucción breve pero potente de hacer algo, o le indicamos el siguiente paso, reforzándolo con instrucciones de «cómo y para qué». El agente avanza y «toca» el siguiente paso, donde de nuevo puede esperarlo o bien un bloqueo con recopilación de datos, o bien un nuevo direccionamiento. Así, encadenando paso a paso, se construye un recorrido del escenario más determinista.
En más detalle sobre en qué se diferencian los distintos tipos de instrucciones y cómo funcionan, en la sección «Comparación de las instrucciones del escenario».
Qué se acumula en el contexto y cuándo se reinicia
Mientras el agente recorre el diálogo, acumula contexto de trabajo: las señales detectadas, la visibilidad actual de los pasos (qué está abierto, qué está oculto tras su ejecución), el contexto del escenario (los datos escritos por la acción «Actualizar contexto del escenario») y las tareas del dashboard: recopilar los datos de un paso, pasar a otro paso, ejecutar una instrucción recibida.
Por defecto, todo este contexto se reinicia al cerrar el diálogo, para que la siguiente solicitud del mismo cliente empiece desde cero y no arrastre el estado de la conversación anterior. Esto lo controla el ajuste «Borrar el contexto del agente cuando se cierre el diálogo» (activado por defecto, ver «Configuración del agente»).
Si el ajuste se desactiva, al cerrar no se reiniciará nada de lo enumerado: las tareas y el contexto sobrevivirán al cierre y pasarán al siguiente diálogo. Esto hace falta cuando el trabajo debe continuar a través del cierre, pero entonces lo acumulado hay que limpiarlo manualmente con la acción «Borrar tareas del agente». Se añade a un paso para el cierre del diálogo o en los puntos del escenario necesarios, para que el agente no se confunda con tareas obsoletas. En la acción se puede elegir qué tipos retirar exactamente: «Recopilación de datos del paso», «Transición a otro paso del escenario», «Instrucciones personalizadas», «Contexto de los pasos».
Importante: incluso con el ajuste activado, el cierre no reinicia todo. Sobreviven al cierre:
- los valores de las variables de estado, escritos por la acción «Cambiar variable del estado»: se conservan a propósito entre los diálogos de un mismo chat. Si ese indicador debe actuar solo dentro de una sola solicitud, reinícialo manualmente, por ejemplo en un paso para el cierre del diálogo;
- los recordatorios creados manualmente con la acción «Ejecución diferida del paso»: si hace falta, también se retiran manualmente. (Los recordatorios del sistema —el de espera de respuesta y el de inactividad del diálogo— se retiran automáticamente al cerrar, independientemente de este ajuste.)
Prueba cada paso en el chat de prueba
Conviene probar cada paso nuevo enseguida en el chat de prueba: ahí se ve qué tareas le plantea el sistema al agente en el dashboard y cómo reacciona a ellas.
Un detalle importante: en los registros del trabajo del agente las tareas del dashboard no se ven. Son datos dinámicos: se calculan en el momento del trabajo y no se acumulan en la conversación. En el historial quedan solo las acciones concretas del agente, los pasos invocados y su razonamiento sobre por qué eligió una u otra herramienta. Por eso, el chat de prueba es la forma principal de ver lo que el agente ve en realidad.
Cómo elegir la estructura del escenario
La arquitectura del escenario conviene elegirla según las funciones y tareas de cada agente: no hay una única estructura correcta.
En un extremo está el escenario poco acoplado: los pasos existen de forma más o menos independiente, cada uno resuelve su propia tarea, y el agente los invoca según las descripciones de los pasos y las instrucciones del prompt, de forma libre. Este enfoque le da al agente mucha libertad de acción, pero conservas el control sobre qué acciones se ejecutan y qué datos trae el agente. Va bien donde la conversación es impredecible y la flexibilidad importa.
En el otro extremo está el escenario determinista: muchos pasos enlazados entre sí por los que el agente debe avanzar en una secuencia fija, recopilando por etapas los datos necesarios o haciendo el trabajo mediante acciones internas. Este enfoque es apropiado en los tramos complejos o críticos, donde la previsibilidad importa y no se puede saltar un paso.
A menudo la mejor solución es combinar ambos enfoques: donde el agente necesita flexibilidad, dejarle un paso libremente disponible, y los tramos complejos o críticos dividirlos en una secuencia de pasos enlazados y describirlos en detalle.
Dónde trazar exactamente la línea, ayuda a entenderlo la fase de pruebas. Poco a poco notas los puntos donde el comportamiento del agente deja de ser estable: esa es la señal de que ese tramo conviene dividirlo en etapas-pasos separadas.