Cómo funciona el motor de orquestación de ElevenAgent

ElevenAgents funcionan gracias a un motor de orquestación de baja latencia diseñado para conversaciones en tiempo real, añadiendo menos de 100 ms de retraso. Esta arquitectura combina lo mejor de la investigación de ElevenLabs con LLMs de vanguardia de proveedores líderes como OpenAI, Google y Anthropic, junto a modelos open-source seleccionados y alojados por ElevenLabs. Al usar varios modelos en diferentes etapas del flujo de respuesta, el agente garantiza conversaciones muy ágiles y con contexto. Aprovechando dinámicamente los puntos fuertes de cada modelo, conseguimos un rendimiento fiable y escalable en tareas empresariales y escenarios conversacionales, optimizando el equilibrio entre inteligencia, velocidad y coste.

En este artículo, explicamos cómo estos modelos trabajan juntos para ofrecer las capacidades clave que los agentes necesitan en entornos complejos, y en concreto, qué modelo ve qué tokens y cuándo. El eje central es la gestión del historial de conversación en los distintos puntos de la interacción. Repasaremos cómo y dónde se comparte el historial de conversación para aclarar su papel en la orquestación, tanto en flujos independientes como en flujos multiagente.

Agente independiente

Empezamos analizando el agente independiente y sus componentes principales. Es razonable considerar que el agente más básico tiene un prompt de sistema, acceso a varias herramientas y una base de conocimiento. Es recomendable usar agentes independientes en lugar de flujos de trabajo cuando el caso de uso no requiere verificar una secuencia estricta de pasos o cuando es importante evitar silos de conocimiento entre agentes. Los silos de conocimiento surgen cuando ciertas herramientas, documentos o contexto histórico solo están disponibles para algunos subagentes y no para otros. Esto es inherente a los flujos multiagente y supone un equilibrio entre flexibilidad y determinismo.

En los agentes independientes de ElevenLabs, es importante entender cómo:

• Formulan solicitudes de generación efectivas
• Recuperan e incorporan documentos relevantes
• Generan y ejecutan llamadas a herramientas para informar las respuestas del agente
• Muestran resultados para evaluación y recogida de datos

Construir el contexto de la conversación 

Una conversación entre un cliente y un agente de ElevenLabs es una serie de turnos, donde cada turno consiste en un intercambio de mensajes entre ambas partes. Esta lista alterna de mensajes de agente y usuario es el punto de partida para construir el contexto conversacional. En cada turno, el LLM recibe solicitudes de generación que contienen una serie de mensajes alternos de agente y usuario, siendo un mensaje más larga que el turno anterior. Esta serie de mensajes siempre empieza con un mensaje de sistema que representa el prompt del agente.

El orquestador de ElevenLabs reduce la latencia percibida del LLM prediciendo cuándo el usuario ha terminado de hablar. En algunos casos, esto puede dar lugar a varias solicitudes de generación al LLM con el mismo contexto conversacional dentro de un solo turno. Aunque la orquestación optimiza la rapidez de respuesta, la calidad depende tanto de cómo se accede al conocimiento. A medida que los clientes avanzan, suelen empezar a fundamentar las respuestas de sus agentes en una combinación de documentación propia y contenido público. Desde hace años, la generación aumentada por recuperación (RAG) es el enfoque estándar para esto.Las bases de conocimiento de ElevenAgents mejoran RAG con una arquitectura multimodelo optimizada que explicamos en una entrada anterior. Esto permite recuperar documentos de forma fiable incluso cuando la última entrada del usuario es un seguimiento, una confirmación o no contiene una pregunta explícita.

La recuperación, sin embargo, es solo una de las formas en que los agentes interactúan con sistemas externos.

Tomar acciones y recuperar información usando herramientas

Los agentes de ElevenLabs pueden realizar acciones reales y obtener información en directo durante la conversación gracias a un sistema flexible de herramientas. Esto implica una consideración importante: cada herramienta habilitada aumenta el tamaño del prompt serializado, ya que su nombre, descripción y esquema de parámetros se incluyen junto al prompt de sistema y el historial de conversación. Cuantas más herramientas se añaden, mayor es la carga de razonamiento para que el modelo elija la secuencia correcta. En el Agent Builder, la descripción de la herramienta explica qué hace y qué campos devuelve. Esta es la información que el modelo de lenguaje usa para entender el contexto de uso. Una vez definida, las condiciones específicas para invocar la herramienta deben estar en el prompt de sistema del agente. Por ejemplo:

• Descripción de la herramienta lookup_order: “Recupera los detalles de un pedido del cliente por ID de pedido. Devuelve estado del pedido, artículos comprados, dirección de envío y número de seguimiento.”
• Instrucción en el prompt de sistema: “Después de verificar la identidad del cliente, llama a la herramienta lookup_order para recuperar los detalles de su pedido.”

Esta separación permite reutilizar definiciones de herramientas entre agentes, mientras que el prompt de sistema de cada agente controla el momento exacto en que se invoca una herramienta. Para ayudar a los clientes a diseñar estos prompts de sistema, ofrecemos más detalles en nuestra Guía de Prompting. Dentro de este marco, se pueden definir varios tipos de herramientas, principalmente:

• Herramientas webhook que llaman a APIs externas.
• Herramientas cliente que envían solicitudes como eventos por websocket de la conversación.
• Herramientas de sistema para acciones integradas como transferencias de llamada.
• Herramientas MCP que conectan con servidores Model Context Protocol.

Cuando un agente decide usar una herramienta, extrae los datos necesarios de la conversación y envía una solicitud para ejecutarla. Cuando la herramienta devuelve un resultado, este se añade a la conversación para que el modelo pueda referirse a él en su siguiente respuesta. Si es necesario, la salida de la herramienta también puede actualizar la información almacenada del agente como una variable dinámica. Esta información se guarda como pares clave-valor simples, extraídos de la respuesta de la herramienta mediante mapeos predefinidos. Una vez establecidas, estas variables pueden usarse en el prompt de sistema, en parámetros de futuras herramientas y en condiciones de flujo. Este ciclo de retroalimentación da a los agentes una especie de memoria de trabajo que evoluciona con la interacción.

Aunque esto describe cómo se integran las herramientas en el razonamiento del agente, el momento de su ejecución también se puede configurar. Las herramientas pueden ejecutarse en tres modos, según la necesidad conversacional. En Modo Inmediato, la herramienta se ejecuta en cuanto el LLM la solicita. Es el modo por defecto para consultas rápidas donde el usuario espera una respuesta casi instantánea, como comprobar el estado de un pedido. Si se combina con un mensaje previo, el agente primero genera una breve confirmación como “Déjame comprobarlo” y la envía al usuario mientras la herramienta se ejecuta en paralelo, minimizando los silencios. Para herramientas más lentas, la plataforma amplía automáticamente estos mensajes de relleno para ajustarse al tiempo de espera. El Modo Post-Herramienta, en cambio, retrasa la ejecución hasta que el agente termina de hablar. Esto es esencial para acciones con consecuencias reales, como transferir una llamada, finalizar una sesión o enviar un pago. El usuario escucha el contexto completo, por ejemplo “Ahora te paso con facturación”, y puede interrumpir antes de que se realice la acción. El Modo Asíncrono ejecuta la herramienta completamente en segundo plano sin pausar la conversación. Este modo es ideal para operaciones tipo “enviar y olvidar”, como mandar un email, activar un workflow externo o registrar datos, donde el agente no necesita referirse al resultado en su respuesta.

Con la ejecución y orquestación listas, el siguiente paso es saber cómo medir el rendimiento.

Medir el rendimiento

Tras finalizar una llamada con un agente, los clientes pueden querer extraer partes de la llamada para analizarlas o almacenarlas, o para saber si la llamada fue exitosa. Aquí es donde entran en juego la Recogida de datos y los Criterios de evaluación. La recogida de datos te permite extraer información estructurada de la transcripción de la llamada para análisis posteriores. Los clientes suelen exportar estos datos a su data lakehouse empresarial para informes o flujos de enriquecimiento. Por ejemplo, un agente de ventas puede extraer automáticamente los datos de un posible cliente de una conversación para crear o actualizar un lead en el CRM. Por otro lado, los criterios de evaluación determinan si una llamada se considera exitosa. Si se cumplen todos los criterios configurados, la llamada se marca como exitosa; si no, se marca como fallo. Así, las conversaciones cumplen siempre los estándares definidos de calidad e integridad, y se obtiene feedback rápido. Al terminar la llamada y activarse el webhook post-llamada, el agente procesa la transcripción final, incluyendo cualquier ejecución de herramienta y metadatos, con un LLM junto a todos los puntos de recogida de datos y criterios de evaluación configurados. El modelo usa este prompt combinado para decidir si se cumple cada criterio y extraer los datos especificados para análisis posteriores. Como el LLM interpreta estas configuraciones directamente en su prompt de entrada, es importante que estén claras y consistentes para que el modelo las entienda y aplique correctamente. Por eso recomendamos estas buenas prácticas para redactar criterios de evaluación y descripciones de recogida de datos.

Criterios de evaluación

1. Un objetivo claro por criterio: una frase o viñeta corta es mejor que varios objetivos en un solo criterio.
2. Observables y basados en la transcripción: formula el objetivo para que el éxito o fallo se pueda decidir a partir de la transcripción (lo que se dijo, lo que hizo el agente, lo que pidió el usuario). Evita objetivos que requieran contexto externo que el LLM no tiene.
3. Resultados explícitos de éxito/fallo/desconocido: el LLM ya sabe que para marcar como éxito el objetivo debe cumplirse, como fallo si no se cumple, y como desconocido si no puede saberlo por la transcripción. Por tanto, el objetivo debe estar escrito para que “cumplido” y “no cumplido” estén bien definidos; si es ambiguo, el modelo puede tender a desconocido o clasificaciones incorrectas.
4. Sé conciso: a veces se envían muchos criterios juntos. Si son largos, pueden añadir ruido y causar alucinaciones.
5. El idioma importa: cualquier explicación que dé el LLM sobre si se cumple un criterio se dará en el mismo idioma que la descripción, así que tenlo en cuenta.

Recogida de datos

1. Describe exactamente qué extraer: la descripción es la señal principal para el LLM. Explica qué significa el campo, en qué situación debe rellenarse y qué hacer si no está claro (por ejemplo, “Déjalo en null si el cliente no indicó una fecha preferida”).
2. Haz que coincida con el tipo esperado: el valor que da el LLM siempre coincidirá con el tipo de dato asignado (booleano, string, entero, etc). Así que la descripción debe ajustarse a eso. Por ejemplo, “Extrae el número de artículos solicitados” para entero, y “Sí/No si el cliente aceptó la oferta” para booleano.
3. Usa enums cuando sea posible: para tipo string, si el conjunto de valores es fijo, usa enum en el esquema; así limitas el modelo y reduces salidas no válidas.
4. Un objetivo de extracción por elemento: No mezcles hechos no relacionados en una sola descripción; divide en elementos separados para que cada llamada tenga un objetivo claro.
5. Mantén las descripciones cortas: Pueden ser unas frases; no hace falta un párrafo largo. La transcripción ya está en el mensaje del usuario, así que el esquema + descripción breve es suficiente.

Actualmente, el LLM usado para esta evaluación y extracción es un modelo de baja latencia para asegurar rapidez. Próximamente, esperamos ofrecer opciones para dar más flexibilidad a los clientes.

A continuación, nos centramos en casos de uso que requieren orquestación estructurada, determinismo o especialización en varios roles conversacionales, donde se pueden usar flujos de trabajo.

Flujos de trabajo

Flujos de trabajo ofrecen una interfaz visual para diseñar flujos de conversación complejos. Al final, generan el objeto lógico que usa el orquestador para gestionar varios subagentes, herramientas y transferencias bajo un identificador de agente independiente. Los flujos de trabajo añaden componentes adicionales a tener en cuenta, además de los ya mencionados para agentes independientes, incluyendo cómo:

• Interactúan los prompts de sistema y los objetivos conversacionales de los subagentes.
• Se determina el recorrido por los distintos puntos de transición del grafo.

Objetivos conversacionales especializados

Los flujos de trabajo reutilizan funciones de los agentes independientes para mantener un comportamiento coherente durante toda la interacción. Esto incluye elementos compartidos como el prompt de sistema base, herramientas principales y bases de conocimiento globales que siempre deben estar disponibles, sin importar la parte activa del flujo. El prompt de sistema general suele definir el contexto conversacional global, el tono esperado, las restricciones de seguridad y cualquier instrucción de marca o producto.

Sobre esta base compartida, los flujos de trabajo introducen subagentes especializados que operan en un grafo dirigido. Cada subagente tiene un objetivo muy concreto y amplía la configuración base con instrucciones adicionales, herramientas y fuentes de conocimiento relevantes solo para su función. En vez de redefinir toda la configuración conversacional, los subagentes añaden su intención sobre el agente base mediante composición de prompts y extensión selectiva de contexto. Aunque el historial de conversación se mantiene entre transiciones de subagente para asegurar continuidad, cada subagente opera con una visión limitada y controlada del sistema. Las bases de conocimiento y herramientas se exponen de forma selectiva, creando silos claros que evitan fugas entre responsabilidades. Para reforzar este aislamiento, el objeto orquestador se reconstruye en cada transición como si fuera un agente independiente. Así, el estado del prompt, la configuración y las capacidades disponibles del subagente activo son totalmente deterministas. Este diseño permite que los flujos de trabajo mantengan coherencia global y especialización local, logrando un comportamiento predecible, separación clara de funciones y control preciso sobre cómo se aplica el contexto, el conocimiento y las acciones en cada etapa de la interacción.

Uno de los mecanismos clave para este control es cómo se gestionan las transiciones entre subagentes.

Transiciones en flujos de trabajo con condiciones LLM

Los flujos de trabajo avanzan recorriendo un grafo dirigido de subagentes, donde las transiciones entre nodos se controlan mediante condiciones explícitas. Estas condiciones determinan cuándo pasar el control de un subagente a otro y permiten que los flujos respondan a la entrada del usuario, resultados de herramientas y variables dinámicas. Las condiciones del grafo pueden ser deterministas o evaluadas por LLM. Las condiciones deterministas, como transiciones incondicionales, comprobaciones basadas en variables dinámicas o resultados de herramientas, garantizan el flujo de control y son ideales para avanzar de forma estricta por el flujo. Las condiciones basadas en LLM, en cambio, permiten evaluar criterios en lenguaje natural, como detectar la intención del usuario o reconocer cuándo se ha dado cierta información.

Es importante destacar que las condiciones LLM se evalúan fuera del prompt de sistema del agente activo y no influyen en el comportamiento de generación del agente. En su lugar, el orquestador las evalúa en paralelo según el estado actual de la conversación. Así, la lógica de transición no contamina el prompt del agente ni afecta a las respuestas, pero los flujos pueden aprovechar el razonamiento LLM para recorrer el grafo con flexibilidad. Combinando condiciones deterministas y evaluadas por LLM, los flujos de trabajo logran previsibilidad y adaptabilidad: usando transiciones deterministas donde la corrección es crítica y transiciones LLM donde se requiere interpretación semántica.

Cuando una conversación pasa a una nueva etapa, el sistema activa una versión del agente adaptada a ese paso. Cada etapa funciona con instrucciones propias y acceso solo al conocimiento y herramientas relevantes para su responsabilidad. Por ejemplo, una etapa de gestión de reembolsos puede consultar políticas de reembolso sin heredar contexto de onboarding o triaje. El paso entre etapas se rige por condiciones de transición explícitas. Estas condiciones determinan cuándo cambiar de responsabilidad y permiten que las decisiones de enrutamiento ocurran de forma natural según avanza la conversación. Para mantener la continuidad, la experiencia del usuario es fluida entre transiciones, heredando el contexto relevante sin exponer la mecánica interna. También hay salvaguardas que monitorizan las transiciones para evitar ciclos improductivos, asegurando que el flujo siga siendo estable y orientado al objetivo.

Seguridad y protección

En casos que requieren controles adicionales de seguridad y protección, los clientes pueden apoyarse en partes extra del orquestador.

Guardarraíles

Los agentes de ElevenLabs aplican guardarraíles de seguridad mediante un sistema configurable de moderación y alineamiento que evalúa los mensajes de usuario y agente en tiempo real. El contenido entrante se clasifica en varias categorías de riesgo, como contenido sexual, violencia, acoso, odio y autolesiones, cada una con umbrales configurables de forma independiente. Si se activa un guardarraíl, la conversación se termina de inmediato y el cliente recibe una notificación clara con el motivo. Así se bloquean interacciones inseguras desde el principio y de forma constante, sin depender solo de mitigaciones en el prompt. Los guardarraíles funcionan fuera de la lógica del prompt del agente, proporcionando una capa de control que no puede ser eludida por el modelo ni por el usuario. Este enfoque permite ajustar la sensibilidad de seguridad según el sector, manteniendo la aplicación determinista en tiempo real.

Gestión de datos conforme a normativa

A veces, los interlocutores pueden compartir información sensible con un agente que está sujeta a requisitos estrictos de almacenamiento y procesamiento, como datos médicos que requieren tratamiento conforme a HIPAA. Para estos casos, ofrecemos el Modo Sin Retención (ZRM) a nivel de agente o espacio de trabajo. Cuando está activado, todos los datos de la llamada se procesan solo en memoria y nunca se guardan de forma persistente. Al finalizar la llamada y el procesamiento, ElevenLabs no retiene ninguna información. Por tanto, las transcripciones, grabaciones y análisis no están disponibles en el panel de agentes, y esta política se aplica tanto a sistemas de cara al cliente como a logs internos. Aunque los datos no se retienen, sí se procesan durante la llamada, y cualquier webhook post-llamada recibirá los resultados, permitiendo a los clientes guardar transcripciones o análisis en sus propios sistemas si lo necesitan.

Cuando ZRM está activo, también nos aseguramos de que los subprocesadores no retengan datos, restringiendo los LLMs disponibles a proveedores con compromisos contractuales que prohíben el entrenamiento o retención de datos de clientes; actualmente, esto incluye modelos de Google Gemini y Anthropic Claude. Los clientes que quieran usar otro LLM bajo ZRM pueden hacerlo firmando su propio acuerdo con ese proveedor y configurándolo como LLM personalizado mediante API keys cubiertas por ese acuerdo. Como esto amplía el tratamiento de datos fuera de nuestro marco estándar de confianza, nuestro equipo de Seguridad debe revisar y aprobar manualmente el caso antes de activarlo. Aunque ZRM garantiza que ElevenLabs y sus subprocesadores no retienen datos de llamadas, los clientes siguen siendo responsables de que cualquier herramienta externa o webhook usado por su agente cumpla con los requisitos normativos y de retención aplicables.

Mirando al futuro

En este artículo hemos visto cómo los agentes de ElevenLabs gestionan el contexto conversacional, las herramientas, la evaluación y los flujos estructurados para ofrecer experiencias fiables y en tiempo real a gran escala. A medida que los clientes despliegan agentes en entornos cada vez más complejos, seguimos ampliando la flexibilidad de nuestro motor de orquestación, desde modelos de evaluación configurables y controles de transición más ricos hasta mayor visibilidad sobre la composición de prompts y uso de tokens en cada etapa.

Nuestro equipo de Forward Deployed Engineering colabora estrechamente con los clientes para que estas capacidades evolucionen al ritmo de los despliegues reales. La próxima generación de agentes ofrecerá aún más transparencia, determinismo y adaptabilidad sin sacrificar la baja latencia que hace posible la conversación en tiempo real.