Agentforce Guía para lograr un comportamiento fiable de los agentes: un marco con 6 niveles de determinismo

Olfa Kharrat, directora de Gestión de Productos - Agentforce
Reinier van Leuken, director sénior de Gestión de Productos - Agentforce

La confianza ha sido el valor central en Salesforce desde su fundación en 1999, como pionera en un nuevo modelo tecnológico de computación en la nube y SaaS. Las empresas depositan su confianza en Salesforce al almacenar datos valiosos en la nube, ya que tienen la tranquilidad de que sus datos están protegidos y se rigen por los controles de acceso adecuados. La confianza sigue siendo un aspecto esencial, pero en la era de la IA agéntica, la definición de este término es aún más amplia. Dado que las empresas dependen cada vez más de agentes autónomos para llevar a cabo funciones críticas, estos deben convertirse en socios comerciales de confianza cuyo trabajo sea preciso, relevante y, sobre todo, fiable.

Dicho esto, ¿cómo se crea un agente fiable? La fiabilidad suele traducirse en ofrecer el mismo resultado para una misma entrada. Sin embargo, los agentes no funcionan necesariamente así, ya que se basan en modelos de lenguaje grandes (LLM), cuya naturaleza es no determinista. Eso da a los agentes la fluidez necesaria para desarrollar soluciones creativas adaptadas a circunstancias específicas, sin necesidad de tener que programar explícitamente cada condición o situación que encuentren. Sin embargo, los agentes también necesitan control para cumplir con los requisitos empresariales y las directrices operativas. Cuando ejecuten procesos de negocio, deben ser fiables y generar resultados empresariales que se ajusten a restricciones deterministas. El determinismo impone una rigidez y una disciplina que chocan con la autonomía y la fluidez que proporcionan los agentes. Por ello, la clave para crear agentes fiables es encontrar el equilibrio adecuado entre la fluidez creativa y el control empresarial.

Este documento aborda consideraciones clave para desarrollar agentes fiables. Define seis niveles de control agéntico y sugiere prácticas recomendadas para hacerse con el control del comportamiento de los agentes y mantenerlo en cada uno de estos niveles. En la guía se aborda cómo funciona el motor de razonamiento de Agentforce. A medida que Agentforce crezca, este documento se actualizará para reflejar las prácticas recomendadas más recientes.

Este documento presupone que el lector está familiarizado con los aspectos básicos del diseño y la creación de agentes de Agentforce. Para una introducción a Agentforce, recomendamos lo siguiente:

• Revisar los recursos en agentforce.com.
• Seguir la ruta Conviértase en un campeón Agentblazer . Esta ruta aborda conceptos básicos de IA y le ayuda a desarrollar un agente básico para tareas clave.
• Obtenga más información sobre Agentforce en help.salesforce.com , y específicamente sobre diseñar e implementar agentes . Esta ruta de aprendizaje le guía a través de todos los pasos clave del ciclo de vida del agente, desde la ideación de su solución y la configuración, hasta las pruebas, la implementación y la supervisión.

Para comprender mejor el comportamiento de los agentes, resulta útil compararlos con sus homólogos rígidos: los chatbots.

Chatbots: seguidores de reglas rígidos

Los chatbots siguen árboles de decisión predeterminados que estructuran los diálogos en los que pueden participar. El recorrido a través de estos árboles de decisión se basa en la respuesta dada por el usuario. Esta respuesta puede ser una selección de un conjunto predeterminado de opciones, o puede ser una respuesta de texto libre. En caso de una respuesta de texto libre, se utiliza un modelo predictivo para clasificar la intención. Estos árboles trazan todas las posibles rutas de conversación y dictan las respuestas del chatbot en cada paso. El comportamiento del chatbot está rígidamente determinado por reglas preestablecidas. Si la entrada del usuario no coincide con una ruta reconocida, o si el modelo predictivo no ha sido entrenado para reconocer una determinada intención, el chatbot no responde adecuadamente.

Agentes: adaptativos e intuitivos

Por el contrario, los agentes aprovechan el poder de los LLM y sus capacidades avanzadas de procesamiento de lenguaje natural (NLP). Los LLM permiten a los agentes comprender la intención que hay detrás de la entrada de un usuario, incluso si está redactada de una forma no prevista. En función de cómo haya entendido la intención, el agente selecciona la acción más adecuada entre una gama de posibilidades. El agente puede incluso formular respuestas completamente nuevas. Esta flexibilidad y adaptabilidad diferencian a los agentes de sus homólogos, los chatbots.

Analogía culinaria

La diferencia entre chatbots y agentes se puede comparar con el contraste entre un cocinero novato y un chef experimentado.

• El cocinero principiante (chatbot) suele basarse en una receta detallada, con medidas precisas, instrucciones paso a paso y tiempos de cocción específicos. Cualquier cambio en la receta acaba en desastre. De igual modo, el chatbot debe funcionar dentro de los límites de su árbol de decisiones preprogramado.
• El chef experimentado (agente) posee años de experiencia culinaria y con su intuición. Con una idea general de las preferencias del cliente y una breve descripción de los ingredientes disponibles, el chef es capaz de preparar una comida deliciosa que se adapte a las necesidades de cada comensal. Los pasos exactos pueden variar cada vez, y cada versión del plato puede tener diferencias sutiles, pero el resultado general siempre es satisfactorio. Del mismo modo, el agente puede adaptar su enfoque en función del contexto y la intención de la entrada del usuario, lo que da como resultado una interacción satisfactoria.

En resumen, la diferencia fundamental entre los agentes y los chatbots radica en su adaptabilidad y capacidad para gestionar entradas inesperadas.

Una característica distintiva de la inteligencia de un agente reside en su capacidad para organizar y desencadenar las acciones más adecuadas en el momento oportuno. Esta flexibilidad elimina la necesidad de programar exhaustivamente cada posible interacción del usuario.

En Agentforce, la creación de un agente incluye temas, acciones e instrucciones y descripciones en lenguaje natural.

Temas

Los temas son las "tareas por hacer" del agente. Los temas tienen atributos como la descripción de una clasificación, el alcance o las instrucciones que definen cada tarea y cómo se realiza. Los temas contienen acciones que el agente puede ejecutar, junto con instrucciones que determinan cómo se ejecutan estas acciones.

Acciones

Las acciones son las tareas predefinidas que el agente puede realizar para hacer su trabajo. Hay cinco tipos diferentes de acciones:

• Ejecutar código Apex
• Llamar a una API
• Ejecutar un flujo
• Obtener una respuesta del LLM a una plantilla de solicitud
• Llamar a un modelo predictivo

Instrucciones y descripciones en lenguaje natural

La definición de un agente contiene instrucciones en lenguaje natural que describen los activos del agente y definen las pautas dentro de las cuales debe operar. Las instrucciones se escriben para acciones y temas.

• Acciones. Una acción contiene:
  • Instrucciones que describen lo que hace la acción, lo que indica al motor de razonamiento cuándo ejecutarla.
  • Entradas con una descripción en lenguaje natural para que el agente pueda prepararlas.
  • Resultados con una descripción en lenguaje natural de cómo darles formato y utilizarlos.
• Tema. Un tema contiene instrucciones que determinan cómo ejecutar sus acciones en un nivel superior. Por ejemplo, las instrucciones pueden especificar salvaguardas sobre el tono de voz, la secuencia de acciones deseada, los posibles requisitos previos o cuándo derivar las conversaciones a humanos. El tema también contiene una descripción de la clasificación y una delimitación del ámbito. En conjunto, esto garantiza que el agente se mantenga dentro del ámbito de su función definida y realice el trabajo.
• Datos. Los agentes necesitan datos para poder hacer bien su trabajo. Los datos pueden ser estructurados, como los datos de CRM, o no, como los artículos de conocimiento de la empresa. Los agentes acceden a los datos mediante entradas de acción. Por ejemplo, una acción puede llamar a una plantilla de solicitud basada en datos de CRM o completada con fragmentos de datos no estructurados mediante técnicas de RAG.

Estos componentes, cuando se crean correctamente, ayudan al agente a cumplir su finalidad prevista mientras opera dentro de los límites establecidos.

El motor de razonamiento de Agentforce organiza estos componentes básicos para conseguir un comportamiento agéntico adecuado. Utiliza las instrucciones y descripciones en lenguaje natural definidas en temas y acciones. Se basa en React, un nuevo paradigma de razonamiento para los LLM introducido en 2022 por Yao et al. Este paradigma imita la gestión humana de tareas cuando razona sobre un problema, toma medidas, observa los resultados de las medidas y repite el ciclo hasta completar la tarea.

Los agentes de Salesforce se adhieren a este paradigma:

1. Razonamiento: entender la intención del usuario y alinearla con el tema y la acción correctos.
2. Acción: lanzar la cadena de acciones correcta.
3. Observación: evaluar los resultados de la acción en función de la intención del usuario. Si la intención no se cumple, razona más en función del resultado obtenido hasta el momento, y en las instrucciones y descripciones del tema/acción. Si se cumple, proporciona la respuesta final respetando las posibles instrucciones de formato.
4. Repetición: iterar estos pasos hasta que se alcanza el paso final indicado.

El motor de razonamiento recurre al LLM en cada paso de razonamiento y observación. Dependiendo del tipo de acción, también puede usar el LLM en el paso de acción.

En esta sección se describe un enfoque por capas para mejorar el determinismo de los agentes. Cada nivel se desarrolla a partir del anterior, con una complejidad y capacidades crecientes que establecen un mayor control sobre el comportamiento del agente.

El primer nivel se centra en permitir a los agentes identificar de forma autónoma temas relevantes y, a continuación, seleccionar las acciones adecuadas utilizando objetivos en lugar de instrucciones explícitas. El mecanismo central consiste en utilizar una comprensión contextual para responder a las entradas del usuario. Aunque técnicamente se puede añadir cualquier tipo de acción, en este nivel, asumimos que las acciones son acciones de solicitud. Los temas sin instrucciones con acciones de solicitud proporcionan una forma rápida y eficaz de gestionar las consultas más frecuentes.

En este nivel, se hace hincapié en establecer un nivel básico de capacidad de respuesta y autonomía del agente mediante la comprensión dinámica.

Partiendo de la base de la selección de acciones sin instrucciones, este nivel introduce instrucciones explícitas para guiar el comportamiento del agente. Incorporar instrucciones precisas aumenta el control sobre cómo responden los agentes a diferentes situaciones. Las instrucciones dirigidas a los agentes pueden expresarse en forma de normas, directrices, salvaguardas y ejemplos, y proporcionan al agente pautas específicas sobre cómo manejar diversos temas, ejecutar acciones y procesar los resultados. El objetivo de este nivel es orientar con claridad al agente para aumentar la coherencia y mejorar el cumplimiento de las directrices y los procesos de la empresa.

La fundamentación consiste en conectar la comprensión y las respuestas del agente con fuentes de conocimiento externas. La fundamentación ayuda a garantizar la precisión, actualización y relevancia de la información proporcionada por el agente. Este nivel integra el acceso a bases de datos, bases de conocimiento y otros repositorios de información. Fundamentar las respuestas del agente en datos verificados mejora su fiabilidad y credibilidad.

Este nivel añade la capacidad de los agentes de trabajar con variables. Las variables permiten a los agentes personalizar las interacciones, conservar el contexto a lo largo de varias interacciones y ajustar dinámicamente su comportamiento en función de puntos de datos específicos mantenidos durante la sesión del agente. Por ejemplo, un agente podría recopilar las preferencias del usuario, los detalles del pedido y otra información relevante, y luego utilizar esos datos para personalizar la interacción. Con las variables, los agentes pueden gestionar mejor interacciones más complejas, más pautadas y más personalizadas.

Este paso integra el agente con las funcionalidades principales de Salesforce: Apex, API y flujo. La integración permite al agente realizar acciones complejas dentro del ecosistema de Salesforce, como acceder a datos y manipularlos, activar flujos de trabajo e interactuar con otros sistemas.

• Apex proporciona control programático.
• Las API permiten una integración fluida con otras aplicaciones
• Los flujos permiten automatizar procesos empresariales complejos.

Este nivel transforma al agente en una potente herramienta capaz de ejecutar tareas sofisticadas y contribuir directamente a los resultados empresariales.

Este último nivel se basa en las integraciones técnicas del nivel 5 e introduce razonamiento determinista para hacer las veces de puente entre la IA probabilística y la lógica empresarial rígida. Mientras que los niveles anteriores dependen del LLM para decidir la herramienta que se usa, el guionado de agente le permite "codificar" el proceso de razonamiento en sí. Con un lienzo estilo documento o código directo, puede definir rutas inmutables, como puertas de autenticación obligatorias, ramificación condicional si/si no y transiciones forzadas de temas, que el agente debe seguir independientemente de lo que indique el usuario. Este enfoque de razonamiento híbrido le permite integrar la flexibilidad conversacional de un LLM entre capas de ejecución garantizada. El nivel 6 transforma al agente en un socio de nivel empresarial con confianza cero, capaz de gestionar el cumplimiento normativo de alto riesgo, las divulgaciones requeridas por las normativas y las dependencias complejas de varios pasos con absoluta precisión.

Partiendo de una base de capacidad de respuesta y autonomía del agente, pensemos en un agente que solo consta de temas y acciones, y sus correspondientes descripciones. Podemos usar a este agente de ejemplo para presentar los diferentes pasos del motor de razonamiento, y mostrar cómo se utilizan estas descripciones para seleccionar los temas adecuados y las acciones que se ejecutarán. Al omitir las instrucciones del tema en este ejemplo, podemos observar que los agentes de este primer nivel tienen el mayor grado de libertad en comparación con los agentes de niveles más altos. En el nivel uno, el agente es completamente libre de seleccionar la acción que considere apropiada, y se basa únicamente en la conversación en curso.

Eche un vistazo a estas cuestiones sobre el motor de razonamiento:

• Los ajustes de configuración se fijan para el LLM del motor de razonamiento. Los generadores de agentes no pueden modificarlos. Actualmente, un generador de agentes puede elegir entre un LLM de OpenAI o un LLM de Anthropic alojado en la infrastructure de Salesforce para el razonamiento. Sin embargo, esto está sujeto a cambios a medida que se añadan más modelos.
• Historial predeterminado del motor de razonamiento: cada vez que se realiza una solicitud al motor de razonamiento (pasos 2 a 5), recupera automáticamente el historial de las solicitudes y respuestas más recientes. De este modo, se garantiza que el contexto de la conversación se conserva para el motor de razonamiento. Además de las interacciones con el cliente, estas llamadas al LLM planificador incluyen llamadas al LLM del motor de razonamiento para otras solicitudes, como la selección de temas.

El proceso de razonamiento se compone de cuatro pasos principales:

1. Selección del tema
2. Selección de acciones
3. Bucle agéntico
4. Comprobación de la fundamentación

Los temas están diseñados para mejorar la precisión con la que los agentes clasifican la acción o secuencia de acciones. Cada tema debe incluir acciones semánticamente distintas que puedan pertenecer a una misma descripción concisa de un tema y, por lo tanto, englobarse en una función de agente similar.

El LLM del motor de razonamiento selecciona el tema pertinente (paso 2-3 del diagrama). Selecciona el tema cuya descripción de clasificación coincida en mayor medida con el último enunciado, utilizando una solicitud de tema. Esta solicitud de tema contiene las descripciones de la clasificación de todos los temas y el historial de la conversación. Además de los enunciados y las respuestas de los agentes, el historial de la conversación incluye las acciones ejecutadas y sus resultados. La solicitud incorpora instrucciones cruciales que exigen el análisis dentro del contexto del historial de la conversación y que obligan al LLM a compartir su proceso de pensamiento.

Consideraciones adicionales:

• Junto a los temas visibles, se incorpora automáticamente un tema oculto adicional para los enunciados "Fuera de tema". Este tema se selecciona cuando ningún otro tema existente se ajusta al enunciado. Esto ayuda al agente a evitar errores de clasificación. Este tema no tiene acciones. Solo existe para ayudar al motor de razonamiento a formular una respuesta adecuada más adelante.
• En la solicitud del tema solo se utilizan el nombre y la descripción de la clasificación del tema.
• El LLM del motor de razonamiento puede elegir solo un tema a la vez.
• Las conversaciones pueden dar un giro de forma inesperada. Cada vez que se recibe un enunciado, el motor de razonamiento pasa al paso de selección de tema, lo que significa que se puede seleccionar un nuevo tema con cada nuevo enunciado.

La finalidad de los temas es doble:

1. Reducir el riesgo de confundir al motor de razonamiento agrupando acciones y, por lo tanto, impedir que seleccione las acciones incorrectas.
2. Orientar la selección y ejecución de acciones con instrucciones (más información en Control agéntico de nivel dos: añadir instrucciones).

Al organizar cuidadosamente las capacidades del agente en temas claramente definidos que se componen de acciones relacionadas, el agente opera de manera más eficaz y predecible, y es más fácil de actualizar y ampliar. Hay dos enfoques posibles para el diseño de temas: descendente y ascendente.

• En el enfoque descendente, los temas se diseñan primero como tareas de alto nivel que debe realizar el agente, y luego se definen las acciones individuales para esos temas.
• En el enfoque ascendente, primero se definen todas las acciones individuales, que luego se agrupan en temas.

Ambos enfoques dan buenos resultados si se siguen correctamente.

Enfoque ascendente

En esta sección se explica el enfoque ascendente, ya que se ajusta perfectamente a las razones por las que el motor de razonamiento necesita temas con los que empezar.

Paso 1: Enumerar todas las acciones de agente

Empiece por enumerar todas las acciones específicas que el agente debe ser capaz de realizar. En esta etapa, es mejor ser muy específico que demasiado general. Evite intentar agrupar o simplificar las acciones de forma prematura. El objetivo es crear una visión completa y detallada de lo que puede hacer el agente.

Por ejemplo, en el caso de un agente de servicio al cliente, la lista inicial podría incluir:

• Devolver un pedido: para iniciar el proceso de devolución de un pedido.
• Consultar la disponibilidad de inventario: para verificar si hay existencias de un producto.
• Consultar políticas de cambio de productos: para recuperar información sobre las reglas para cambiar productos.
• Responder preguntas con conocimiento: para responder a preguntas generales o similares a las preguntas frecuentes.
• Consultar promociones: para comprobar si hay promociones o descuentos disponibles.
• Predecir fecha de entrega: para estimar la fecha/hora de entrega prevista.
• Comprobar el estado del pedido: para revisar el estado actual del pedido de un cliente.
• Buscar pedidos de clientes: para recuperar todos los pedidos pasados o activos de un cliente específico.
• Solucionar problemas técnicos: para resolver problemas técnicos con un producto o servicio.
• Buscar términos de pedidos de clientes: para recuperar todos los términos relacionados con un pedido.
• Buscar activos de clientes: para identificar o recuperar activos asociados con un cliente.
• Cambiar la dirección de entrega.

Tenga en cuenta que una acción como "Resolver reclamaciones de clientes" es demasiado general en este momento. Las acciones deben representar el nivel más pequeño de granularidad en el comportamiento del agente. Las reclamaciones pueden ser de muchos tipos, y diferentes acciones ya las abordan:

• Los problemas posteriores a la entrega, como la resolución de problemas de productos dañados o que no funcionan correctamente, ya están cubiertos por "Solucionar problemas técnicos".
• Los problemas previos a la entrega, como entregas perdidas, la necesidad de cambiar las fechas de entrega o la modificación de pedidos, ya están cubiertos por acciones como "Comprobar el estado del pedido", "Predecir fecha de entrega" o "Devolver un pedido".
• Las consultas generales de los clientes, como las preguntas sobre políticas, ya están cubiertas en "Responder a las preguntas con conocimiento" o "Consultar políticas de cambio de productos".

Paso 2: Marcar los pares (o múltiplos) de acciones que puedan causar confusión en el razonamiento

Marque las acciones que sean de naturaleza similar y puedan causar confusión al motor de razonamiento. Sus descripciones no serán lo suficientemente diferentes desde el punto de vista semántico, por lo que el motor de razonamiento no sabrá qué acción seleccionar en el paso 5.

Por ejemplo, "Resolución de problemas técnicos" y "Responder preguntas con conocimiento" tienen descripciones similares, pero su funcionalidad puede diferir significativamente. Marcar estas superposiciones semánticas ayudará a identificar qué acciones separar en varios temas.

Paso 3: Crear agrupaciones iniciales de acciones en temas

Una vez que las acciones están claramente definidas y se han identificado sus solapamientos semánticos, las acciones pueden agruparse en temas preliminares. Un tema es una categoría lógica de funcionalidad, una agrupación de acciones, que juntas representan una capacidad o habilidad coherente del agente.

Al crear estas agrupaciones:

• Evite la superposición semántica utilizando el número mínimo de temas necesarios.
• Asegúrese de que cada tema contenga acciones que estén relacionadas de manera significativa.
• Asegúrese de que las acciones de apoyo que deban ejecutarse en una cadena estén presentes en el mismo tema.

Este es un ejemplo de una agrupación inicial para un agente de servicio al cliente:

Tema 1:

• Devolver un pedido
• Consultar la disponibilidad de inventario
• Consultar las políticas de cambio de productos
• Consultar promociones
• Predecir la fecha de entrega
• Encontrar los términos de pedidos de los clientes
• Comprobar el estado del pedido
• Buscar pedidos de clientes
• Buscar activos de clientes
• Responder a las preguntas con conocimiento
• Cambiar la dirección de entrega

Tema 2:

• Solucionar problemas técnicos
• Buscar activos de clientes

Paso 4: Escribir descripciones de clasificación para los temas y dividir los temas si es necesario

Una vez que tenga la agrupación inicial, escriba descripciones de clasificación para cada tema.

• El tema 2 de nuestro ejemplo trata claramente de problemas técnicos con los productos.
• El tema 1, sin embargo, tiene un ámbito más amplio. Se trata en gran medida de la gestión de pedidos, pero también contiene algunas acciones que no están relacionadas con la gestión de pedidos, como consultar promociones y responder preguntas con conocimiento. El tema 1 no se puede describir de manera clara y concisa en una sola oración y, por lo tanto, el tema debe dividirse en diferentes temas.

Después de ajustar esta cuestión, obtenemos lo siguiente:

• Tema 1: Gestión de pedidos: describe las acciones relativas a la gestión y modificación de los pedidos de los clientes y la logística relacionada, excepto todo lo correspondiente con el cambio y la devolución.
  • Consultar la disponibilidad de inventario: determinar si hay existencias de un producto.
  • Predecir la fecha de entrega: estimar cuándo llegará un pedido.
  • Comprobar el estado del pedido: encontrar el estado del pedido de un cliente.
  • Buscar pedidos del cliente: recuperar todos los pedidos realizados por un cliente.
  • Cambiar la dirección de entrega.
• Tema 2: Resolución de problemas
  • Buscar activos del cliente: recuperar los dispositivos o productos registrados del cliente.
  • Solucionar problemas técnicos: proporcionar asistencia técnica o diagnósticos.
• Tema 3: Cambios: describe las acciones relacionadas con los cambios y la devolución de pedidos.
  • Devolver un pedido: iniciar el proceso de devolución de un pedido.
  • Consultar las políticas de cambio de productos: proporcionar las reglas de cambio para los productos.
  • Buscar pedidos del cliente: recuperar todos los pedidos realizados por un cliente.
  • Buscar términos de pedidos de clientes: recuperar todos los términos relacionados con un pedido.
• Tema 4: Soporte de productos: describe las acciones transversales utilizadas para la recuperación y el enrutamiento de información.
  • Responder a las preguntas con conocimiento: responder a las consultas generales de los clientes utilizando la información de la base de conocimientos.
  • Consultar promociones: consultar las promociones o descuentos actuales.

Para recapitular, primero se crea una lista completa de todas las acciones posibles, luego se marca la superposición semántica entre estas acciones. A continuación, debe crearse un conjunto de temas que, como mínimo, resuelva toda la superposición semántica (para que el motor de razonamiento no se confunda dentro de los límites de un tema). Después, se escribe la descripción de clasificación de cada tema. Si los temas tienen un ámbito demasiado amplio, hay que dividirlos en temas más granulares. Si sigue estos pasos, creará un agente que no solo funcione bien, sino que también sea fácil de mantener y ampliar.

Esta estructura admite un mejor razonamiento, una ejecución más precisa y límites de decisión más claros en el comportamiento del agente. También se basa en la colaboración entre diseñadores, ingenieros y expertos en la materia para hacer que las capacidades del agente sean más transparentes y modulares.

Otras consideraciones para la creación efectiva de temas

• Número óptimo de temas: para mejorar el rendimiento de los LLM a la hora de clasificar el tema correcto, por lo general, es recomendable no exceder los 10 temas. Sin embargo, esto es solo una regla general. También es necesario tener en cuenta que cada tema debe tener una descripción clara y diferenciada. En última instancia, el número óptimo de temas depende de la distancia semántica entre las descripciones de clasificación de temas. Si los temas tienen descripciones de clasificación que difieren mucho, se minimiza el riesgo de superposición de temas. Aquí se describen más prácticas recomendadas para evitar la superposición entre temas.
• Equilibrio entre tamaño y claridad en los temas: si bien generalmente es beneficioso que los temas sean pequeños en términos de acciones e instrucciones para que la clasificación sea más fácil, crear demasiados temas con descripciones muy similares puede generar confusión, al igual que la superposición semántica entre acciones lleva a errores de clasificación. Por ello, es importante que las descripciones de los temas estén claramente diferenciadas semánticamente. Puede usar LLM para ayudarle a crear clasificaciones bien diferenciadas.
• Lenguaje estándar y claridad contextual: es posible que los LLM no conozcan los significados y abreviaturas específicos de la empresa o el negocio. Use un lenguaje estándar o sea muy explícito a la hora de explicar los significados de las palabras dentro de su contexto particular.
• En la solicitud del tema solo se envían el nombre y la descripción del tema. Por lo tanto, cambiar el ámbito o las instrucciones del tema no tendrá ningún impacto en la selección del tema.

Ejemplo en acción

Imagine que un agente de servicio recibe una solicitud sobre la póliza de garantía para un reloj. El tema de la garantía no parece estar relacionado con el cambio o el soporte del producto. La gestión de pedidos parece ser el tema más apropiado para abordar esta solicitud. Por lo tanto, el motor de razonamiento elige este último tema como el más probable para cumplir con la solicitud.

Tras la selección del tema, el motor de razonamiento selecciona las acciones adecuadas que se deben ejecutar a partir del tema seleccionado. Una vez más, el LLM del motor de razonamiento es el responsable de esto, utilizando otra solicitud llamada la solicitud de observación. La finalidad de la solicitud de observación es obtener el siguiente paso en el proceso de razonamiento. El siguiente paso puede ser cualquiera de los siguientes:

• Iniciar una acción
• Solicitar entradas de acción por parte del usuario
• Solicitar al usuario que aclare la solicitud
• Enviar la respuesta final al usuario (cumplir con la solicitud del usuario) una vez que se ha completado el ciclo de la acción (para obtener más detalles, consultar el paso 3 del razonamiento)

La entrada a la solicitud de observación está formada por todas las descripciones de todas las acciones del tema, así como del historial de conversaciones.

Prácticas recomendadas para el diseño de acciones

Las acciones son las tareas predefinidas que el agente puede realizar para hacer su trabajo. Las acciones son las definiciones más detalladas del trabajo. Hay cinco tipos diferentes de acciones de agente: (1) ejecutar código Apex, (2) llamar a una API, (3) ejecutar un flujo, (4) obtener una respuesta de LLM a una plantilla de solicitud y (5) llamar a un modelo predictivo. La mayoría de estas acciones pueden ser deterministas. Una excepción es obtener una respuesta a una plantilla de solicitud (siempre que la acción de Apex, el flujo o el sistema externo no contenga elementos probabilísticos como invocaciones de solicitud). Abordaremos estos temas en el quinto nivel de control agéntico.

1. Controlar el comportamiento de los agentes en acciones de solicitud: Hay dos formas de controlar el comportamiento del agente en las acciones de solicitud: (1) añadir más instrucciones a la plantilla de solicitud mediante la ingeniería de solicitudes, y (2) configurar los hiperparámetros del LLM que genera la respuesta a la solicitud, en particular la temperatura (consulte la documentación ). La reducción de la temperatura reduce la variabilidad en las respuestas generadas, lo que aumenta su repetibilidad y la fiabilidad del agente.
2. Número óptimo de acciones dentro de un solo tema: similar al número máximo de temas, el número de acciones dentro de un tema no debe ser superior a 10. Pero, de nuevo, esta es una regla general. El factor realmente determinante es la distancia semántica entre las acciones. Cuando las acciones se distinguen claramente por su descripción, este número puede ser mayor. Sin embargo, no existe una medida numérica para la distancia semántica; depende de la interpretación del generador de agentes. Cuanto mayor sea la diferencia de significado entre las descripciones de las acciones, mayor será la distancia semántica. Aquí se debe evitar la superposición en todo momento.
3. Descripciones de las acciones: Contrariamente a lo que sugiere el nombre, la "instrucción de acción" en realidad sirve como una instrucción que el LLM del motor de razonamiento usa para seleccionar la acción correcta del tema. Tenga en cuenta que el uso de descripciones de acciones semánticamente distintivas puede mejorar considerablemente la calidad de sus clasificaciones. Revise cuidadosamente estas descripciones y, sobre todo, compare todas las descripciones de acciones que pertenezcan a un mismo tema.

Ejemplo en acción

Continuemos con el ejemplo anterior en el que un agente de servicio recibe una pregunta sobre la política de garantía de un reloj. Después de seleccionar el tema Gestión de pedidos, se elige la acción más probable. Dado que este es el tema de gestión de pedidos, el primer paso lógico es buscar el pedido (de lo contrario, ¿para qué se recupera la información de la garantía?) iniciando la acción de búsqueda de pedidos.

Un enunciado del usuario puede desencadenar la ejecución de varias acciones antes de que se envíe una respuesta al usuario. Esto se debe al bucle agéntico, que continúa seleccionando y ejecutando la siguiente acción más adecuada hasta que se cumple una de las siguientes condiciones:

• El LLM del motor de razonamiento determina que la solicitud está completa. En este caso, se determina que la respuesta satisface la solicitud del usuario. Tenga en cuenta que parte de esta comprobación incluye una comprobación de la fundamentación, que verifica que la respuesta se fundamenta en las salidas de acción. El LLM del motor de razonamiento no debe inventar ninguna información en la respuesta, ya que esto podría dar lugar a respuestas incorrectas o alucinaciones.
• No se encuentran más acciones adecuadas.
• Se alcanza el máximo permitido de llamadas al LLM para el paso actual. Este número lo establece el propio motor de razonamiento.

Las acciones no están sujetas a un tiempo de espera específico. Esto es para evitar interrupciones cuando los tiempos de ejecución de las acciones varían en función de su complejidad. Algunas acciones son simplemente más complejas de ejecutar que otras.

Ejemplo en acción

Después de iniciar una búsqueda de pedido, el motor de razonamiento evalúa la respuesta generada hasta el momento y decide si es necesario realizar más tareas antes de enviar una respuesta al usuario. Ahora que el pedido aparece en el historial de conversaciones, es el momento de consultar la política de garantía.

Sin embargo, al hacerlo, el agente se da cuenta de que el cliente ha comprado dos relojes, tal y como se ha recuperado mediante la acción "búsqueda de pedidos". Por lo tanto, en el bucle agéntico, el motor de razonamiento decide ahora pedir al cliente que especifique para qué reloj en concreto necesita información sobre la garantía.

Evitar guiones demasiado rígidos

Es importante evitar definir en exceso la forma en que los agentes deben conversar con los usuarios. El exceso de guionización puede limitar la capacidad de un agente para establecer una buena relación con el cliente, comprender sus necesidades específicas y responder de manera eficaz en tiempo real a circunstancias dinámicas. Además, las instrucciones largas pueden ralentizar la respuesta del agente y confundir al motor de razonamiento. Forzar el determinismo mediante instrucciones no es el enfoque preferido.

Quéno se debe hacer

Por ejemplo, no es necesario decirle a un agente que evite referirse a los competidores en las respuestas de servicio. Esto puede dar lugar a comportamientos no deseados, ya que el agente también puede negarse a responder a preguntas relacionadas con la integración con un proveedor que a la vez sea un competidor. En su lugar, la instrucción puede ser algo así como "Cuando se hable de la competencia, responde teniendo en cuenta los intereses de la empresa". De este modo, se evitan instrucciones restrictivas y condicionales como "Menciona solo al competidor xyz en el caso de...", y se aprovechan las capacidades de razonamiento del LLM. En este ejemplo se muestra cómo es posible dar instrucciones a un nivel más general y abstracto, de forma similar a como se formaría a un empleado humano tras incorporarse al departamento de atención al cliente de la empresa.

Veamos algunos ejemplos más de lo que no se debe hacer. A continuación, se muestran algunas instrucciones formuladas incorrectamente, proporcionadas a un agente de servicio que gestiona perfiles de candidatos en un sitio web de contratación. Estas instrucciones intentan anticipar todas las posibles respuestas de los clientes y, por lo tanto, deben evitarse:

Instrucción 1: El agente recibe el siguiente enunciado: "¿Puedo añadir una imagen a mi perfil?" A continuación, pregunta inmediatamente al cliente: "¿Qué tipo de perfil tienes?"

Instrucción 2: Si el cliente indica que tiene un perfil premium, responde "Déjame comprobar los detalles de tu contrato", busca los detalles del contrato y comprueba si, en el contrato, se acordó que se podía actualizar la foto de perfil.

Si se acordó que el candidato puede hacerlo, responde "Sí, es posible; puedo encargarme de actualizarla". ¿Puedes proporcionar tu nueva foto?" Una vez que se reciba la imagen, actualiza el perfil del candidato en consecuencia. Si el contrato no incluye cambios en la foto del perfil, diga di "Lo siento, no es posible". "Voy a derivarte a un agente humano".

Instrucción 3: Perfil no premium: Si el cliente indica que tiene un perfil no premium, responde "No puedes actualizar la foto. Si deseas hacerlo, dímelo y te transferiré con un agente humano".

Instrucción 4: Si no queda claro el tipo de perfil, responde "No he entendido tu tipo de perfil".

Qué hacer en su lugar

En lugar de este tipo de control minucioso, es preferible aplicar un enfoque más flexible que oriente el comportamiento y la conducta de los agentes. Es importante tener en cuenta las siguientes prácticas recomendadas:

1. Utilizar RAG o acciones de conocimiento para las políticas y reglas que están en los artículos de conocimiento (en vez de escribirlas como instrucciones). La información relevante se recuperará en el momento adecuado. En el ejemplo anterior, eso significa que el artículo de conocimiento titulado "Actualización de imágenes" debe indicar: "Solo los candidatos con un perfil premium cuyo contrato permita cambiar la foto pueden actualizar su foto".
2. Describir las pautas y salvaguardas principales individualmente, independientemente de la conversación. Es esencial dar a los agentes una explicación clara y concisa del comportamiento o procedimiento esperado en cuestión.

Según estas prácticas recomendadas, un conjunto de instrucciones más adecuado podría ser el siguiente:

Instrucción 1 : “Utiliza acciones de conocimiento para comprobar las políticas en caso de solicitudes de cambios en la cuenta".

Instrucción 2 : No respondas a preguntas para las que no se haya encontrado ninguna política aplicable".

La aplicación de las pautas anteriores puede mejorar los resultados del agente. Ahora, si el cliente solicita al agente un cambio de perfil, el agente comprenderá que necesita recuperar la política requerida de la base de conocimiento, interpretar las reglas recuperadas, aplicar esas reglas al contexto y, finalmente, responder al cliente. A diferencia de la guionización excesiva, este enfoque conductual es mucho más genérico y ampliamente aplicable. Sin tener que escribir cada conversación posible, el agente ahora puede responder de manera flexible con el comportamiento deseado a una gama más amplia de temas de conversación.

Forzar la secuencia de acciones (no aplicable para guionado de agente)

La solicitud de observación incluye instrucciones y descripciones de acciones, pero sin un orden definido. Si la secuencia de acciones es crítica, debe indicarse explícitamente dentro de la misma instrucción. Tenga en cuenta que, con el guionado de agente, podemos forzar cumplir un orden de ejecuciones gracias a las transiciones. Esto se explicará con más detalle en el sexto capítulo.

Sigamos con el ejemplo de los agentes del sitio web de contratación. El agente debe ser capaz de gestionar la planificación de las entrevistas con el entrevistador adecuado. Para ello, debe comprobar primero la disponibilidad de los responsables de selección y, a continuación, proponer tres posibles franjas horarias al candidato.

En este caso, para mantener el orden de ejecución, las instrucciones no deberían estar en cuadros separados:

1. Instrucción 1: Comprueba la disponibilidad de los entrevistadores.
2. Instrucción 2: Entonces, propón a los candidatos las franjas horarias adecuadas.

Estas instrucciones no funcionan porque el motor de razonamiento no sabe a qué se refiere "Entonces" en la instrucción 2. Esto se debe a que las instrucciones se envían al motor de razonamiento como un grupo, sin ningún orden en particular.

En su lugar, las instrucciones que definen la secuencia deben combinarse en una sola instrucción y escribirse así:

1. Instrucción 1: Comprueba la disponibilidad de los entrevistadores. Entonces, propón a los candidatos las franjas horarias adecuadas.

Forzar la salida de una acción sin modificarla

El motor de razonamiento es en sí mismo un LLM. Es responsable de generar la respuesta final de acuerdo con el bucle agéntico. Este enfoque es necesario para hacer cumplir las instrucciones del agente que proporcionan salvaguardas para la generación de respuestas, o para combinar los resultados de múltiples acciones que formaban parte del bucle agéntico, con el fin de satisfacer la solicitud del usuario.

Sin embargo, cuando la expectativa es que solo se ejecute una acción de solicitud, se puede implementar una instrucción para indicar al agente que nunca cambie la salida de una acción. De este modo, se garantiza un comportamiento más predecible y fiable por parte de los agentes.

Imponer este cumplimiento estricto en las plantillas de solicitudes aprobadas resulta crucial en determinados escenarios, especialmente cuando la coherencia, el cumplimiento y los mensajes predefinidos son importantes. A continuación, se incluyen dos ejemplos:

• Sectores industriales regulados: las organizaciones que operan en sectores altamente regulados (como el financiero, el sanitario o el jurídico) suelen requerir un control estricto de todas las comunicaciones con los clientes. Las plantillas de solicitud aprobadas garantizan que las respuestas cumplan con los requisitos legales y normativos, lo que minimiza el riesgo de malas interpretaciones, responsabilidades o difusión de información inexacta.
• Respuestas probadas y validadas previamente: las plantillas de solicitud se pueden someter a pruebas y validaciones rigurosas para garantizar la precisión, la eficacia y los resultados deseados. Desviarse de estas plantillas puede socavar su eficacia y valor. El cumplimiento estricto garantiza que los mensajes probados se entreguen de manera coherente.

Esta instrucción limita la libertad del agente para cambiar la salida de las acciones. Asegúrese de que la instrucción hace referencia a la salida de la plantilla de solicitud (como "promptResponse"), como se muestra en este rastreador de planes.

En este caso, la instrucción puede ser:

“ No cambiar la salida de promptResponse, independientemente del canal del agente ”.

Limitaciones en la aplicación del cumplimiento estricto:

Cuando una interacción requiere múltiples acciones distintas por parte del agente, no es viable exigir el cumplimiento estricto de una única plantilla. De hecho, en este escenario, el motor de razonamiento necesita consolidar estas acciones en una única respuesta y, por lo tanto, cambiar cada uno de los resultados de las acciones.

Número óptimo de instrucciones

Según las características generales del LLM, el número objetivo de instrucciones oscila entre 5 y 10, dependiendo de la complejidad de las instrucciones y de la interacción entre ellas. Estas características de las instrucciones influyen en el número de instrucciones que puede seguir el motor de razonamiento:

• Claridad y especificidad: las reglas bien definidas son más fáciles de seguir.
• Conflictos entre reglas: si las reglas se contradicen entre sí, se requiere lógica adicional para resolver esos conflictos.
• Longitud y complejidad: si cada regla requiere un razonamiento profundo, es mejor dividirlas en instrucciones más pequeñas.

Si es muy importante seguir una instrucción explícitamente, es importante añadir términos que reflejen su importancia:

• Urgencia e importancia (inmediata, urgente, crítica, esencial, obligatoria)
• Autoridad y cumplimiento (requerida, obligatoria, estrictamente aplicada)
• Consecuencias y advertencias (la infracción resultará, el incumplimiento conducirá, el incumplimiento puede llevar a, se aplican sanciones estrictas, tolerancia cero)
• Claridad y concisión (debe, prohibido, no permitido, siempre/nunca)

Fundamentar las respuestas en datos mejora significativamente la fiabilidad y credibilidad de los agentes. Las respuestas fundamentadas se basan en información objetiva en lugar de en especulaciones o conocimientos obsoletos. La generación aumentada por recuperación (RAG) es una técnica ampliamente adoptada que permite a un agente acceder y utilizar una base de conocimientos para formular respuestas más precisas y contextualmente relevantes. En función de la consulta del usuario, el agente emplea la RAG para recuperar información relevante de las fuentes de datos aplicables y, a continuación, completa la solicitud con esta información antes de enviarla al LLM. Los agentes que recurren a la RAG ofrecen una mayor calidad, precisión y utilidad general en las interacciones, lo que aumenta la confianza y la satisfacción de los usuarios. Las prácticas recomendadas para la RAG se describen de manera detallada en el documento técnico disponible públicamente Agentforce and RAG: best practices for better agents.

Conocimiento e instrucciones

Es importante diferenciar entre conocimientos e instrucciones a la hora de encontrar el equilibrio adecuado entre orientación y flexibilidad, ya que cumplen funciones diferentes:

• Conocimiento: piense en el conocimiento como la biblioteca de libros a la que tiene acceso el agente mientras genera sus respuestas. Algunos ejemplos son documentos, artículos de conocimiento o documentos técnicos. Tenga en cuenta que estos pueden incluir políticas y reglas generales de la empresa. El conocimiento también puede referirse a archivos transaccionales, como correos electrónicos, transcripciones de llamadas e incluso el historial de conversaciones (de agentes). Finalmente, el conocimiento incluye campos de texto largo en datos estructurados. El conocimiento generalmente se lleva al agente a través de la RAG.
• Instrucciones: piense en las instrucciones como el conjunto mínimo de reglas para orientar al agente sobre cuándo debe utilizar cada acción. Las instrucciones también pueden establecer salvaguardas para toda la conversación, como el tono de voz que se debe utilizar. A menudo, las instrucciones pueden ser más concisas y flexibles sin sacrificar la claridad ni la intención. En lugar de proporcionar un guion rígido con respuestas específicas para cada posible situación con un cliente, considere la posibilidad de implementar directrices y principios generales que ayuden al agente a seleccionar la acción o acciones adecuadas en diversas situaciones.

Generación aumentada por recuperación

La generación aumentada de recuperación (RAG) actúa como una capa de datos inteligente para el conocimiento. Brinda a los agentes acceso a información en varios formatos y proporciona fragmentos de texto relevantes para responder preguntas. Con la RAG, los agentes pueden obtener respuestas de LLM más precisas sin saturar la solicitud del LLM con contenido superfluo ni exceder su ventana de contexto.

En tiempo de ejecución, la RAG ejecuta tres pasos:

1. Recuperación: el sistema de IA busca en una gran base de datos o fuente de conocimiento para recopilar información relevante para la solicitud de LLM. Esto se hace mediante la búsqueda semántica, una técnica más sofisticada en comparación con la búsqueda tradicional basada en palabras clave. A diferencia de la búsqueda por palabras clave, que encuentra términos exactos, la búsqueda semántica entiende el significado o el contexto detrás de las palabras. Identifica la información relevante basándose en los conceptos o las relaciones entre los términos, en lugar de limitarse a buscar coincidencias exactas entre palabras. La búsqueda por palabras clave también puede desempeñar un papel importante en este proceso de recuperación, reforzando la búsqueda semántica con la coincidencia de palabras clave para terminología o nombres específicos. Este tipo de búsqueda se denomina búsqueda híbrida.
2. Aumento: la información recuperada se añade a la solicitud.
3. Generación: el LLM genera una respuesta contextualmente apropiada y más precisa gracias a la solicitud aumentada (o completada) con el conocimiento recuperado.

En Agentforce, la RAG se puede utilizar con o sin una plantilla de solicitud:

1. RAG basada en solicitudes: en este enfoque, las instrucciones que especifican cómo generar la respuesta se encuentran en las instrucciones de la solicitud en una plantilla de solicitud. En este caso, la respuesta depende completamente de lo que genere el LLM. Aparte de las instrucciones de la solicitud, hay formas de influir en la respuesta, como los ajustes de configuración de LLM en Einstein Studio, pero el resultado sigue sin ser determinista.
2. RAG basada en el motor de razonamiento: en lugar de utilizar una plantilla de solicitud, el agente utiliza una acción que recupera fragmentos (a través de un flujo o una clase Apex) y los almacena en una variable (consulte la siguiente sección). En este enfoque, el motor de razonamiento (en lugar del LLM) genera respuestas directamente, fundamentándose en los datos recuperados. Las instrucciones que rigen la generación de respuestas son instrucciones del agente en lugar de instrucciones de la plantilla de solicitud. La variable que contiene el contenido recuperado se puede pasar explícitamente como entrada a una acción. También se puede proporcionar al motor de razonamiento concediéndole acceso predeterminado al contenido de la variable. Este enfoque tiene ventajas e inconvenientes. Existe el riesgo potencial de sobrecargar el motor de razonamiento con contenido y responsabilidad. Además, a diferencia de una solicitud, los parámetros del LLM del motor de razonamiento no son configurables. Por otro lado, el motor de razonamiento puede generar su respuesta utilizando tanto los fragmentos recuperados como el historial de la conversación.

El método recomendado es la opción 1. Reduce la cantidad de tareas que debe realizar el motor de razonamiento y, por lo tanto, mejora la calidad de su respuesta. En la siguiente sección analizaremos una excepción a esta regla, en la que el contenido se conserva a lo largo de toda la conversación y, por lo tanto, se asigna explícitamente a una acción.

Prácticas recomendadas de RAG

• Evitar las instrucciones de generación aumentada por recuperación rígidas: en lugar de vincular directamente las instrucciones a artículos específicos para preguntas concretas, aprovecha la inteligencia de RAG para encontrar de forma dinámica la fuente de datos más relevante y el fragmento de texto más preciso. El proceso de coincidencia de RAG se basa en una comprensión más amplia de la pregunta, no solo en una correlación exacta entre pregunta y fuente.
• Consolide temas: agrupar categorías de preguntas relacionadas en un solo tema. La RAG puede identificar eficazmente las respuestas relevantes en función del tipo de pregunta, incluso dentro de un tema más amplio. Por ejemplo, los problemas relacionados con el producto, como el mantenimiento y los problemas con la batería, se pueden agrupar en un tema más amplio.
• Almacenamiento del resultado de la generación aumentada por recuperación en una variable: cuando se alcance el número de límites de interacción, conviene guardar el resultado de RAG en una variable. De este modo, la información permanece accesible para orientar las interacciones de los agentes más allá del umbral estándar. En la siguiente sección se proporcionará un ejemplo.

Ciertos procesos de negocio exigen una ejecución aún más predecible, como la aplicación de una secuencia de acciones específica o condiciones para desencadenar acciones o temas.

Para lograr este comportamiento determinista, se pueden usar variables. Las variables funcionan como una forma estructurada de memoria de agente a corto plazo que puede servir como entradas o salidas de acciones. Además, el estado de una variable puede determinar la activación de temas y acciones específicos.

Formas en que las variables respaldan la determinación

Las variables pueden ayudar a lograr el determinismo guiado de los agentes de las siguientes maneras:

1. Fundamentación dinámica persistente: las variables permiten a los agentes actualizar continuamente su comprensión del mundo, al tiempo que conservan información importante que no se ve afectada por ninguna interacción posterior. Este método garantiza que la información crítica, que puede tener la forma de datos no estructurados recuperados a través de la generación aumentada por recuperación (RAG) o de datos estructurados, como la información del perfil del usuario, se conserva durante toda la conversación, independientemente de su duración.
2. Entradas/salidas de acciones: las variables se pueden utilizar como parámetros de entrada y salida para las acciones. La acción se refiere explícitamente a variables, y la ejecución de la acción no depende del motor de razonamiento para establecer esas entradas y salidas, lo que aumenta el determinismo del agente.
3. Filtrado: las variables se pueden utilizar para determinar la ejecución condicional de acciones o temas. Las variables permiten un flujo específico de información entre las acciones y el determinismo en la ejecución de la acción. Esta capacidad es especialmente importante para las reglas de seguridad en las que no se pueden iniciar acciones si no se verifican variables de entrada específicas, como el correo electrónico.

Tipos de variables en Agentforce

Agentforce tiene dos tipos de variables:

• Las variables de contexto son variables generadas por el sistema que contienen información sobre el usuario y las sesiones de conversación.
• El usuario puede crear instancias de variables personalizadas. Contienen cualquier tipo de información utilizada para cualquiera de las tres formas en que las variables respaldan el determinismo.

Cada tipo de variable incluye una serie de capacidades:

Profundicemos en las variables con un ejemplo de caso de uso: un agente de resolución de problemas orientado a los clientes. En este ejemplo, las variables se utilizan para las tres finalidades: fundamentación dinámica persistente, entradas/salidas de acciones y filtrado.

En este ejemplo, el agente ayuda a un cliente a solucionar un problema técnico del dispositivo. La resolución de problemas generalmente implica realizar una serie de pasos. El agente debe ofrecer una experiencia de servicio que imite el trabajo de un agente humano. Para ello, el agente no debe proporcionar a la vez todos los pasos de la resolución del problema al cliente. En su lugar, debe ofrecerle instrucciones paso a paso, junto con la capacidad de pasar de un paso a otro (incluida la posibilidad de volver a pasos abordados anteriormente) en función de cómo responda el cliente.

Uno de los retos que esto plantea es la capacidad del agente para recordar todos los pasos de resolución de problemas a lo largo de la conversación. Dada la memoria limitada del agente debido al número restringido de interacciones que puede almacenar, estos pasos pueden eliminarse del contexto del motor de razonamiento si la conversación se alarga.

La forma de abordar este problema es utilizar una variable para fundamentar el motor de razonamiento de forma dinámica en todos los pasos de resolución de problemas. Al recuperar la información y almacenarla en una variable, permanece disponible y se puede actualizar a lo largo de la conversación. El motor de razonamiento utiliza la información almacenada en esta variable para la fundamentación dinámica.

En este ejemplo, un tema incluye dos acciones. Estas dos acciones son necesarias para mantener un flujo de datos coherente. La primera acción se usa para rellenar la variable que contiene todos los pasos de resolución de problemas. La segunda acción usa esa variable durante la resolución de problemas en sí.

1. Acción 1: "Rellena los pasos de resolución de problemas". Esta es la acción inicial, desencadenada por la primera introducción del agente al problema. Utiliza la generación aumentada por recuperación para extraer todos los pasos de resolución necesarios de una base de conocimiento indexada. La acción almacena la salida resultante en una variable denominada "Pasos de resolución".
2. Acción 2: "Utilizar en medio de la resolución de un problema". Esta es una acción basada en una solicitud que genera el siguiente paso de resolución de problemas más probable que se utilizará durante el proceso de resolución del problema. Se indica al agente que use esta acción mientras está resolviendo un problema.

La pregunta original del cliente se incluye como entrada en ambas acciones. La segunda acción tiene otra entrada: el contenido de la variable "Pasos de resolución". Esta variable se ha establecido por la primera acción. Tenga en cuenta que la segunda acción no recuperará los pasos de resolución de problemas por sí misma, sino que los obtendrá como entrada de la primera acción a través de la variable. En el diagrama siguiente se muestra el flujo de datos entre esas dos acciones.

La acción "Utilizar en medio de la resolución de un problema" siempre hará referencia a los pasos de resolución de problemas originales recuperados por la acción Pasos de resolución de problemas. Este flujo de datos garantiza que los pasos de solución de problemas se mantengan de forma coherente y siempre presentes, independientemente de la duración de la conversación.

Para ejecutar las acciones definidas en este ejemplo, se necesitan instrucciones específicas, como "Ejecuta siempre primero los 'pasos de resolución Rellenar'". Sin embargo, dada la naturaleza no determinista de los LLM utilizados por los agentes, esto puede conducir a un orden diferente en ciertos casos. Para garantizar un orden determinista de ejecución, introducimos filtros condicionales en estas variables para aplicar la secuencia de acción adecuada. El agente lee el valor de la variable "Pasos de resolución" y define dos filtros en función de si esta variable tiene un valor o no.

• La acción "Pasos de resolución de problemas" solo se puede ejecutar si la variable "Pasos de resolución" está vacía.
• La acción "Utilizar en medio de la resolución de un problema" solo se puede ejecutar si se completa la variable "Pasos de resolución".

Estos filtros condicionales ahora aplican de forma determinista la secuencia de ejecución de la acción: "Utilizar en medio de la resolución de un problema" debe esperar a que "Pasos de resolución de problemas" complete su tarea, lo que garantiza que la variable "Pasos de resolución" siempre tenga un valor.

Para garantizar la ejecución correcta de la acción, se necesita una tercera acción para restablecer la variable "Pasos de resolución" si el problema se resuelve por completo. Como resultado, el agente se restablece al estado requerido para ayudar con un posible problema nuevo y diferente. Esta tercera acción se llama "Vaciar la variable de resolución". El diagrama de acciones completo se muestra a continuación.

Las variables son fundamentales para que nuestro agente de resolución de problemas pueda resolver los problemas de los clientes, ya que permiten:

• Fundamentación dinámica persistente: las variables almacenan los pasos para solucionar problemas, lo que garantiza que estén disponibles durante toda la conversación, independientemente de la duración o el número de interacciones. Esto evita que el agente olvide el contexto.
• Flujo de datos: las variables facilitan el flujo de datos entre acciones. Por ejemplo, la variable "Pasos de resolución" almacena los pasos de resolución de problemas recuperados de la acción "Pasos de resolución de problemas" y los proporciona como entrada a la acción "Utilizar en medio de la resolución de un problema".
• Determinismo: las variables se pueden usar como filtros para aplicar un orden específico de ejecución de acciones. Por ejemplo, la acción "Utilizar en medio de la resolución de un problema" solo se ejecuta si se completa la variable "Paso de resolución", con lo que se garantiza que la acción "Pasos de resolución de problemas" se ejecute primero.

En la era de la IA generativa, la IA predictiva sigue siendo de vital importancia, ya que constituye la inteligencia fundamental que guía, mejora y contextualiza las capacidades generativas. Mientras que la IA generativa se centra en crear contenido nuevo, como texto, imágenes o vídeos, los modelos predictivos hacen predicciones sobre el futuro basándose en datos empresariales en tiempo real. Algunos ejemplos de resultados empresariales son las probabilidades de pérdida de clientes, las probabilidades de conversión, las probabilidades de derivación de casos, el valor vitalicio de los clientes y la clasificación de casos. Las predicciones pueden ayudar a anticipar las necesidades de los usuarios, personalizar los resultados, tomar decisiones y optimizar la relevancia del contenido en tiempo real, todo ello mediante el análisis de tendencias y cifras. Por ejemplo, en aplicaciones como el aprendizaje personalizado, la asistencia sanitaria o la planificación financiera, la IA predictiva garantiza que los resultados generativos se ajusten a los contextos individuales y a los posibles escenarios futuros. Juntas, la IA predictiva y generativa crean una potente sinergia, en la que se fusionan la previsión y la creatividad para impulsar soluciones tecnológicas más inteligentes, adaptables y con mayor impacto.

Cómo integrar los resultados de los modelos predictivos en los flujos de trabajo de los agentes

Para incorporar los resultados de los modelos predictivos a los flujos de trabajo de los agentes, simplemente basta con añadir acciones de modelos predictivos a los activos de Agentforce. El Generador de modelos proporciona los medios para crear o registrar (BYO) modelos predictivos, que luego son utilizados por el agente para realizar predicciones. Las predicciones resultantes (así como los predictores) se pueden almacenar en variables personalizadas. Los agentes pueden utilizar estos valores variables como entradas y condicionar la ejecución de acciones y temas específicos.

Ejemplos de casos de uso integrados con modelos predictivos

• Segmentación: realiza una clasificación multiclase para la segmentación de clientes y utiliza el segmento resultante para filtrar determinadas acciones. Por ejemplo, reserva acciones premium para clientes de nivel premium.
• Probabilidad de derivación: predice la probabilidad de derivación de un caso de servicio. Si esta probabilidad supera un cierto umbral, permite la ejecución de acciones que resuelvan el caso más rápido o derívalo a agentes humanos más rápido.
• CPG: planifica una promoción solo si el aumento de las ventas (puntuación calculada por un modelo predictivo) supera un determinado umbral.
• Comercio: propón un producto solo si la inclinación a comprar supera un cierto umbral.

Ciertos procesos empresariales deben ejecutarse en un orden preciso y no requieren la intervención del usuario durante su ejecución. En este caso, se puede aplicar un flujo de pasos predeterminado mediante flujos, API o Apex. Si tiene un flujo existente en el que se basa la producción, es una buena indicación de que el agente puede conservarlo y utilizarlo para la ejecución de ese proceso empresarial. Todos los ejemplos siguientes incluyen secuencias predeterminadas de pasos que el agente puede ejecutar sin necesidad de intervención del usuario. El comportamiento agéntico en este caso consiste en identificar qué proceso determinista ejecutar, cómo recopilar los datos necesarios y cómo interpretar y procesar los resultados.

Los procesos empresariales con muchos pasos secuenciales (más de tres, como regla general) y muchas dependencias de variables se vuelven demasiado complejos y engorrosos de aplicar con instrucciones. En este caso, es posible codificarlos directamente utilizando los tipos de acción deterministas que se enumeran en esta sección. Por último, tenga en cuenta que estas implementaciones pueden incluir elementos no deterministas, como llamar a LLM con plantillas de solicitud resueltas. Por lo tanto, no necesariamente son completamente deterministas de principio a fin, y aún así pueden demostrar los niveles de fluidez deseados por los que los agentes son conocidos.

La secuencia de pasos en un recorrido de marketing está condicionada por reglas fijas y no depende de ninguna entrada conversacional del usuario. Por lo tanto, el flujo se puede utilizar como una acción de Agentforce. Se puede crear una acción invocable para completar tareas en segundo plano o activadas por eventos desde un componente de solución que puede llamar a un flujo o a una clase Apex. Añada una acción invocable a un flujo o clase Apex y especifique la tarea que debe completar el agente, así como las condiciones que lo activan. Las acciones invocables también pueden incluir las variables de contexto del agente y transmitir información importante.

Los flujos de Salesforce se pueden utilizar para automatizar tareas rutinarias, como crear tareas de seguimiento, enviar correos electrónicos de recordatorio o actualizar registros. Los flujos hacen que el trabajo sea más eficiente y productivo. Los agentes también pueden ejecutar flujos mediante acciones de flujo. Debido a su determinismo, los flujos son una excelente manera de dirigir el comportamiento agéntico cuando un proceso empresarial debe ejecutarse en una secuencia particular. Una buena indicación de que es preferible una acción de flujo es si el tema contiene instrucciones como "Primero haz esto, luego haz esto y, por último, haz esto". Hacer cumplir secuencias de más de tres pasos resulta complicado de gestionar mediante instrucciones y variables.

Los flujos también pueden incluir elementos no deterministas mediante llamadas a las solicitudes. Un nodo de solicitud en el flujo invoca una plantilla de solicitud y recopila la respuesta que se puede pasar a otros elementos del flujo. Estos elementos adicionales pueden ser nuevamente nodos de solicitud, por ejemplo, resumiendo la respuesta anterior, creando así una cadena de solicitudes. Esto resulta especialmente útil cuando las reglas del encadenado de solicitudes se definen mediante elementos fijos y no dependen de la entrada del usuario. Un ejemplo es la RAG agéntica, en la que una secuencia predefinida de recuperadores o solicitudes en un flujo puede acceder a fuentes de datos específicas en un orden concreto, como recuperar inicialmente datos del documento del país de un usuario antes de consultar otras fuentes según sea necesario. Este mecanismo de encadenado impone una extracción fiable y ordenada de información relevante.

Al igual que las acciones de flujos, las acciones de Apex y API son deterministas, ya que se puede codificar una secuencia predefinida de acciones. Estas acciones pueden incluir elementos no deterministas, como invocar plantillas de solicitud o llamadas al LLM. Sin embargo, en su definición, ejecutan estos pasos de forma determinista, lo que reduce la variabilidad del agente al llamar a la acción en el momento adecuado, recopilar la información necesaria y procesar el resultado. Estas responsabilidades aún deben regirse por instrucciones agénticas, por lo que no son deterministas. Las acciones de Apex y API son el equivalente en código profesional de las acciones de flujo.

Del razonamiento probabilístico al determinista

En los niveles de determinismo 1 a 5, agregamos progresivamente estructura al entorno del agente. Definimos lo que podía hacer (nivel 1, temas), luego guiamos cómo debía comportarse (nivel 2, instrucciones), lo fundamentamos en verdades (nivel 3, datos), gestionamos su estado (nivel 4, variables) y le proporcionamos herramientas rígidas (nivel 5, acciones deterministas). Sin embargo, el motor central de toma de decisiones siguió siendo fundamentalmente probabilístico. El motor de razonamiento todavía estaba decidiendo por sí mismo qué herramienta elegir o qué pregunta hacer a continuación, y para esta decisión estábamos confiando plenamente en el modelo de lenguaje grande (LLM).

El nivel 6, guionado de agente, cambia radicalmente esta arquitectura. Introduce la capacidad de codificar el propio proceso de razonamiento.

Con el guionado de agente, pasamos de dar solicitudes al modelo a crear scripts para el agente. No se trata de volver a los chatbots rígidos de la vieja escuela. De hecho, nos referimos a esto como razonamiento híbrido. Le permite emparejar el poder creativo y conversacional de un LLM entre capas de lógica determinista e inmutable. Podrá definir explícitamente la ruta crítica de ejecución (lo que "tiene que hacer") al tiempo que deja espacios específicos de libertad para que el LLM gestione la comprensión del lenguaje natural y la generación de respuestas.

Al diseñar flujos de trabajo, es crucial evitar usar mediante guiones agentes basados en LLM solo para luego reemplazar la lógica determinista cuando los próximos pasos ya estén claros y fijos. Si un proceso sigue una ruta predecible sin necesidad de un razonamiento complejo para decodificar acciones posteriores, introducir un modelo generativo añade latencia innecesaria, costes y posibilidades de error. Los flujos de programación tradicionales siguen siendo superiores para procesos puramente deterministas que no necesiten razonamiento. Usar un LLM para enrutamientos sencillos o transiciones lineales es una opción que complica innecesariamente el proceso y compromete la fiabilidad de un sistema que, de otro modo, podría gestionarse mediante un flujo de procedimiento estándar.

Como regla general, plantéese soluciones agénticas cuando el sistema esté tratando con entradas no estructuradas que deben sintetizarse a partir de fuentes dispares y de alta variación (posiblemente incluidas conversaciones) antes de que se pueda tomar una decisión.

Pero, ¿cómo se alcanza este nivel de control? Hay dos rutas distintas, diseñadas tanto para el arquitecto empresarial como para el desarrollador de código profesional.

Llevar el determinismo de nivel 6 a su agente no tiene por qué requerir código. Salesforce proporciona dos modalidades para generar el guionado de agente subyacente, lo que democratiza el acceso al razonamiento determinista.

Para los analistas de negocios, administradores y profesionales de low-code, se puede acceder al nivel 6 directamente desde el generador de agentes.

Hemos introducido un lienzo estilo documento que sirve como interfaz de texto a guión. En lugar de escribir código, escriba la lógica del tema en lenguaje estructurado y natural. A continuación, el generador interpreta su intención y la compila en el guionado de agente en segundo plano.

• Escriba: "En primer lugar, compruebe si el pedido es más antiguo de 30 días. Si es así, dígale al usuario que no podemos aceptar devoluciones y finalice la conversación educadamente. Si no lo es, pregunte por el estado del artículo".
• El sistema compila esta narrativa en lenguaje natural automáticamente en las estructuras if/else, las comprobaciones de variables y los comandos end_conversation que sean necesarios.

Esto le permite escribir la lógica en lenguaje natural y hacer que la plataforma la convierta en código, lo que garantiza que incluso quienes no programan puedan aplicar límites rígidos y determinismo.

Para los desarrolladores que buscan la máxima precisión, también puede escribir un guionado de agente directamente en el generador de agentes. Al lienzo con narrativa en lenguaje natural se le puede “dar la vuelta” para ver el guión subyacente, de modo que el desarrollador ahora pueda modificar el código directamente. Este enfoque permite incluso una experiencia de creación híbrida: algunas instrucciones se escriben en lenguaje natural en el lienzo, mientras que otras se escriben en guiones (o se modifican los existentes) directamente mediante código. Alternando entre estas dos experiencias, comprobará que las dos modalidades siempre se mantienen en perfecta sincronización.

Ambas modalidades sacan todo el partido del nivel 6:

• Seguimiento detallado: Puede echar un vistazo a la ejecución del guión para ver exactamente dónde cambiaron las variables o se siguieron ramificaciones.
• Gestión de bucles complejos: Gestione una lógica de reintento sofisticada o cambios de estado multivariables difíciles de describir en lenguaje natural.
• Control de versiones: Trate el comportamiento de los agentes como código, compatible con los embudos Git e CI/CD para el control de versiones de los agentes.

Tanto si genera guionados de agente a través del generador como si lo hace manualmente, obtiene el mismo resultado: El guionado de agente se convierte en un gráfico de agentes que ejecuta el motor de razonamiento Atlas.

Para dominar el nivel 6, uno debe entender lo que sucede entre bambalinas. El guionado de agente controla el comportamiento a través de estructuras programáticas específicas dentro de bloques de razonamiento. A diferencia de las solicitudes estándar, que son sugerencias que podría seguir el LLM, se trata de comandos que se ejecutarán ocurra lo que ocurra. Eso es antes, durante o después del proceso de razonamiento, y pueden adoptar varios tipos distintos de determinismo. Primero revisaremos algunos de estos patrones en general y veremos algunos ejemplos ligeros, y luego los ilustraremos en más detalle con ejemplos de modelos arquitectónicos de agentes guionizados.

En los niveles 1-5, esperábamos que el agente hiciera algo (realizar una acción) antes o después de un determinado paso en el proceso. En el nivel 6, lo obligamos a hacerlo. Lo que esté escrito en los bloques before_reasoning y after_reasoning siempre se ejecutará, respectivamente, antes y después de invocar el LLM para razonar en función de las instrucciones. Podría ser ejecutar otras acciones, transiciones a temas, establecer variables, etc.

Por ejemplo, mediante el uso del comando run dentro de las instrucciones before_reasoning de un tema, puede ejecutar una acción incluso antes de que se invoque el LLM para generar una respuesta. Esto garantiza que los datos estén disponibles de inmediato, lo que elimina la latencia del razonamiento o el riesgo de que el agente olvide invocar a la herramienta.

Estructura del guión:

Con el determinismo condicional, puede usar la lógica de programación estándar para controlar el flujo. Esto es fundamental para los flujos de trabajo de cumplimiento, donde los pasos no se pueden omitir ni reconcebir.

Estructura del guión:

En este ejemplo, el LLM nunca tiene la opción de alucinar una aprobación para un usuario que no sea VIP. El motor toma la rama de forma determinista.

Otra medida de control potente es la capacidad de forzar al agente a salir del tema actual y entrar en otro. Esto evita que se quede atascado o se desvíe a conversaciones no relacionadas.

Estructura del guión:

Esta transición no es una sugerencia. Es una redirección rígida del flujo de ejecución que depende del valor de una variable. Tenga en cuenta que, si bien la redirección es rígida y no negociable, vuelve a tener lugar un proceso de razonamiento normal dentro del tema al que ahora se ve obligado a pasar el agente.

Además, con el guionado de agente, tiene la capacidad de forzar explícitamente una transición de una acción a la siguiente inmediatamente después de completarla. Esta funcionalidad garantiza que el agente siga un flujo rígido y determinista en lugar de depender de una toma de decisiones probabilística o autónoma en cada paso. Al encadenar estas acciones en una secuencia predefinida, puede garantizar que las tareas específicas se ejecuten en un orden preciso, lo que proporciona un control total sobre la lógica y el comportamiento del agente.

El guionado de agente le da acceso directo de lectura/escritura a la memoria a corto plazo (las variables) del agente. Puede establecer explícitamente variables en función de los resultados de la acción, lo que evita que un LLM pueda interpretar erróneamente los resultados de JSON de una herramienta.

Estructura del guión:

Para comprender realmente el poder del guionado de agente, debemos mirar más allá de los comandos individuales y observarlos cuando trabajan al unísono. Los siguientes patrones arquitectónicos (derivados de nuestra colección de recetas de guionado de agente ) demuestran cómo el determinismo de nivel 6 resuelve desafíos empresariales complejos.

El problema: Los agentes estándar a menudo sufren de latencia durante el razonamiento. Esperan a que el usuario haga una pregunta, luego piensan en qué herramienta usar, luego pueden incluso preguntar al usuario información que ya podría haberse obtenido y solo entonces llaman a la acción. Esto crea una experiencia deficiente e irregular. El guionado de agente: Determinismo previo al razonamiento.

Utilizamos el comando run para inyectar datos incluso antes de que el LLM se despierte.

Ejemplo: El agente de clasificación de emergencias. Imagine a un agente que gestiona un informe de interrupción del suministro eléctrico. En lugar de preguntar al usuario por su dirección y esperar, en el momento en que se inicia la sesión, el guión ejecuta automáticamente un comando get_current_location_by_IP and check_grid_status.

El resultado: El agente no comienza con "¿Cómo puedo ayudarle?" Comienza con: "Veo que llaman desde el sector norte, donde se confirma un incendio en los transformadores. Ya he añadido su hogar a la lista de reparación prioritaria. ¿Dispone de un generador de emergencia funcional?"

La lógica:

Las solicitudes largas (que dan al agente todas las reglas de una sola vez) conducen a una mayor probabilidad de alucinación en el proceso de razonamiento. El agente olvida la regla A porque está mirando la regla Z.

La solución del guionado de agente: Inyección de instrucciones justo a tiempo con fundamentación condicional a través de una combinación de generación aumentada por recuperación y lógica condicional. Solo muestra al agente las reglas que se aplican al momento exacto de la conversación.

Ejemplo: Proporcionar reglas para ofertas no aptas. ¿Para qué vamos a proporcionarle al agente las reglas sobre solicitudes de aumentos de crédito, cuando la puntuación de crédito del cliente ni siquiera le va a permitir que comience el proceso?

La lógica:

La fundamentación condicional evita errores al eliminar por completo la información que distrae cuando no es necesaria.

El problema: En una conversación compleja con un agente (como una solicitud de hipoteca, una entrevista de trabajo o una sesión de resolución de problemas técnicos), el agente mantiene una lista de preguntas que tiene que responder para obtener toda la información necesaria del usuario. Sin embargo, los usuarios a menudo se van por tangentes. Un agente estándar puede seguir la tangente y olvidarse de volver a estas preguntas imprescindibles, dejando la solicitud o la conversación incompleta.

En el corazón de este sistema se encuentra la navegación con estado, que trata la conversación como una lista de verificación rigurosa que debe marcarse por completo antes de que se pueda producir cualquier transición.

A través de la navegación con estado, el agente se mueve entre temas basándose estrictamente en el estado actual de la variable o permanece inamovible dentro de un tema hasta que se cumplan condiciones específicas. Esto evita que el agente siga rutas inadmisibles, incluso cuando un usuario intente descarrilar la conversación con tangentes. Por ejemplo, en una solicitud de hipoteca de alto riesgo, si un usuario pide horarios de apertura de la sucursal, el agente no solo intenta no perder sus objetivos de vista. En vez de eso, el guión detecta la desviación y puede desencadenar una transición forzada a un tema de regreso al cumplimiento. Al bloquear al agente en una "sala lógica" específica, se vuelve matemáticamente imposible que trate temas no aprobados o salga de una sesión hasta que todas las variables imprescindibles se hayan capturado correctamente.

Ejemplo: Un inspector de mantenimiento; un agente está guiando a un técnico por la verificación de seguridad de 10 puntos en un motor de aeronave. El técnico dice: "Espere, también he notado un arañazo en el fuselaje".

Comportamiento:

1. El agente reconoce la idea del arañazo (lenguaje natural).
2. Registra el arañazo en una variable (gestión de estados).
3. Se niega a cerrar la sesión o cambiar de tema hasta que confirme lo siguiente: "He anotado el arañazo del fuselaje, pero no podemos pasar a la inspección 'Exterior' hasta que confirme el ajuste de par en la válvula de admisión. ¿Qué dice esa lectura?"

Lógica:

Sin embargo, una conversación guiada debe ser algo más que una lista secuencial de preguntas. De lo contrario, el agente se parece más bien a un "formulario disfrazado". Su valor principal radica en la clasificación inteligente: usar preguntas de descubrimiento inicial para dirigir al usuario al formulario o flujo de trabajo correcto.

Pasar de un script simple a un guionado de agente sólido es una evolución lógica cuando aumenta la complejidad. En lugar de preguntar solamente, el agente comienza a tomar medidas: Por ejemplo, el agente puede extraer pasos de solución de problemas de la documentación, estudiar políticas internas o ejecutar llamadas a la API a sistemas externos para resolver problemas en tiempo real.

Con la introducción del guionado de agente como nivel 6 en el marco de niveles de determinismo, ahora tiene la gama completa de control, desde la creatividad libre de un tema de nivel 1 hasta la lógica rígida y basada en código de un guionado de agente de nivel 6.

Sin embargo, disponer de un martillo no hace que todos los problemas sean un clavo.

El error más común es pensar que "cuando más arriba, mejor" y que los agentes ahora deben controlarse completamente utilizando un guión para todos los asuntos. Eso no es cierto. El verdadero arte de la arquitectura y el diseño de agentes radica en ajustar el determinismo aplicando exactamente el nivel de control suficiente para garantizar la seguridad, sin sacrificar la flexibilidad conversacional que hace que la IA sea valiosa en primer lugar. No se exceda con la codificación de sus agentes hasta el punto de convertirlos en chatbots con esteroides.

Este capítulo proporciona un marco de decisión para ayudarle a determinar cuándo depender de la autonomía guiada de los niveles 1 a 5 y cuándo aplicar la precisión programada del nivel 6. No son normas estrictas, sino reglas generales, y están destinadas a proporcionar un marco contextual de cómo pensar sobre las diferentes opciones y niveles del determinismo.

Para simplificar la decisión, podemos dividir los seis niveles en dos zonas estratégicas distintas:

• La filosofía: "confiar, pero verificar". Le da al agente el objetivo, los datos y las herramientas (que pueden ser deterministas, como en el nivel 5), pero permite que el motor de razonamiento decida el mejor camino para llegar allí.
• El mecanismo: razonamiento probabilístico. El agente analiza la intención del usuario y selecciona dinámicamente la mejor herramienta para la tarea.
• Ideal para: descubrimiento, preguntas y respuestas generales, tareas de bajo riesgo y ámbitos de servicio amplios.

Debe confiar en los comportamientos probabilísticos estándar de los niveles 1 a 5 cuando:

1. El camino correcto no siempre es el mismo

En muchos escenarios conversacionales, una ruta rígida y codificada es en realidad una desventaja porque la ruta conversacional correcta es variable. Para interacciones dinámicas, como compras personales o planificación de vacaciones, no hay una secuencia única correcta: un usuario podría dar prioridad al precio, la ubicación o los servicios en cualquier orden que elija. En estos casos, forzar un guión con estado crea una experiencia robótica y frustrante, por lo que es más efectivo confiar en las instrucciones para definir la personalidad y los objetivos del agente y permitir al usuario llevar las riendas del flujo. Este enfoque también aumenta significativamente la velocidad de comercialización, ya que crear guiones complejos de nivel 6 con variables y ramas anidadas a menudo es excesivo para tareas como los agentes internos de preguntas frecuentes de RR. HH. Al basar el agente en datos y generación aumentada por recuperación, puede evitar la necesidad de un guión manual exhaustivo y dejar que el motor de recuperación gestione la conversación de forma dinámica en función de su base de conocimientos existente.

2. Ampliación mediante determinismo modular: Cómo evitar la pesadilla del mantenimiento

Cuando su agente alcanza una escala masiva, como la gestión de 500 consultas de soporte de TI diferentes con sus propios procesos, el desafío principal no es si puede crear un único guión agéntico determinista, sino si debe hacerlo. Intentar asignar cada permutación posible de 500 tareas en un guionado de agente gigante genera una pesadilla de mantenimiento. Cada vez que cambie una póliza o se agregue un nuevo paso de solución de problemas, corre el riesgo de romper una red lógica masiva e interconectada.

La solución es alejarse de un guión monolítico y pasar a acciones deterministas de nivel 5. En lugar de crear guiones para toda la conversación, cree flujos sólidos y aislados para las acciones de alto valor de primer nivel, como restablecer contraseñas o desbloquear cuentas. A continuación, permita que el motor de razonamiento actúe como un policía de tráfico, identificando la intención del usuario a partir de su formulación única y dirigiéndolo a la acción determinista adecuada. Este enfoque le ofrece lo mejor de ambos mundos: la fiabilidad de un guión para tareas críticas y una arquitectura flexible y escalable que no se derrumba por su propio peso a medida que crece su biblioteca de tareas.

• La filosofía: "Haga lo que haga y razone lo que razone, haga siempre exactamente esto". Usted define la ruta. El agente es la interfaz que ejecuta su lógica. Envuelve la creatividad del agente en capas de lógica no negociable.
• El mecanismo: El razonamiento determinista. El "cerebro" sigue un gráfico precompilado; el LLM se usa solo para el razonamiento, la comprensión del lenguaje natural y la generación de respuestas donde el guión lo permita.
• Ideal para: cumplimiento, transacciones financieras, árboles de diagnóstico, flujos de trabajo de alto riesgo, cumplimiento y sectores altamente regulados.

Tenga en cuenta que dentro de las vías deterministas que establece el nivel 6, todas las opciones del nivel 1-5 siguen estando disponibles.

Cuando "funciona casi siempre" no basta, pase al guionado de agente.

1. Las puertas de acceso obligatorias (seguridad y autenticación)

Si un usuario solicita transferir dinero, no puede confiar en que el LLM solicite probablemente la autenticación. Necesita una garantía matemática de que el flujo de autenticación se ejecute antes del flujo de transacción.

• La solución del guionado de agente: usar run @actions.verify_identity dentro de un bloque before_reasoning o en la capa superior de su guión para forzar el cumplimiento antes de que el LLM genere un solo token.

2. Cumplimiento normativo

En sectores como la sanidad o las finanzas, los agentes a menudo deben leer al pie de la letra una exención de responsabilidad o hacer preguntas en un orden legalmente obligatorio.

• La solución del guionado de agente: Codifique la divulgación.

3. Dependencias complejas de varios pasos y secuencias de acciones obligatorias

Si el paso B requiere los resultados del paso A y el paso C depende de un cálculo del paso B, es muy arriesgado depender de un LLM para interpretar estas variables por el contexto de la solicitud como si estuviera jugando al teléfono descacharrado. Además, cuando la ejecución de una determinada acción es estrictamente obligatoria después de otra acción, la secuencia debe estar fijada.

• Las solución del guionado de agente: Usar set set @variables.x = @outputs.y para vincular explícitamente los datos entre pasos, lo que garantiza una fidelidad perfecta. Use run y declaraciones @utils.transition para codificar la secuencia.

4. Prevención de la deriva de temas

En la solución de problemas de alto riesgo (por ejemplo, "Mi marcapasos está pitando"), no le interesa que el agente se distraiga si el usuario pregunta de repente: "¿Qué tiempo hace?".

• La solución del guionado de agente Use @utils.transition para bloquear al usuario en el tema del protocolo de emergencia hasta que se resuelva el problema, lo que anula explícitamente la posibilidad de deriva.

Las arquitecturas de agentes más maduras no eligen uno u otro enfoque; utilizan el nivel 6 como esqueleto y los niveles 1–5 como músculo. El patrón que surge entonces es el de una especie de sándwich determinista. Puede utilizar el guionado de agente para gestionar el principio y el final, críticos en una conversación, al tiempo que deja el medio abierto para un razonamiento flexible.

• Paso 1 (nivel 6): El guionado de agente fuerza la clasificación y la autenticación.
  • Resultado: El usuario se identifica de forma segura y la intención se clasifica.
• Paso 2 (niveles 1-5): El guionado de agente hace una transferencia a un tema estándar.
  • Resultado: El agente utiliza generación aumentada por recuperación y acciones, instrucciones y quizás incluso variables estándar para resolver el problema del usuario de forma flexible.
• Paso 3 (nivel 6): El agente detecta que el problema se ha resuelto y vuelve a pasar al guionado de agente para las acciones de cierre.
  • Resultado: El guionado de agente fuerza la recopilación de puntuaciones de CSAT y un lenguaje de despedida que cumple las normas.

Recomendación final: Comience con los niveles 1 a 5 para acelerar y descubrir datos, y supervise sus registros. Si ve que el agente tiene problemas con la coherencia, no es capaz de seguir una secuencia o alucina parámetros, endurezca selectivamente ese flujo de trabajo específico con el nivel 6.

El guionado de agente es la última pieza del rompecabezas a la hora de llevar el determinismo a los agentes. Reconoce que, si bien la IA es probabilística, los negocios son deterministas. Al adoptar el guionado de agente (ya sea a través del lienzo compatible con la creación de agentes en lenguaje natural o en código directo), no está limitando la inteligencia de su agente, sino que la está concentrando. Está creando un sistema en el que el arte de la conversación se une a la ciencia de la ejecución de procesos, lo que garantiza que sus flujos de trabajo más críticos se ejecuten exactamente como se han diseñado, en todo momento.

El nivel 6 también es comprender que autónomo no significa necesariamente sin control.

Durante años, el sector ha tenido un debate entre reglas e IA en lo que respecta a la toma de decisiones y la optimización de procesos. El bando de las reglas estrictas abogaba por la previsibilidad. El bando de la IA abogaba por la flexibilidad. El guionado de agente pone fin a este debate demostrando que la arquitectura correcta no es “esto o lo otro”, sino “esto y lo otro también”.

Al adoptar el guionado de agente, está creando agentes híbridos: sistemas que poseen los rígidos cimientos del código y la mente flexible de un LLM. El futuro de la IA empresarial no esté en los modelos más grandes. Está en un mejor control. Con el guionado de agente, ese control finalmente está en sus manos.