Integración de agentes externos con la orquestación de voz de ElevenLabs Agents

Los orquestadores de agentes de vanguardia cada vez son más capaces de gestionar tareas complejas y operar con todo el conjunto de herramientas empresariales. Esto requiere una gestión rigurosa del estado de la aplicación, la conversación y el sistema. Para modalidades distintas de la voz, han surgido patrones comunes bajo el término general de ingeniería de contexto, cuyo objetivo es establecer prácticas coherentes en torno al prompt de sistema de un agente a medida que avanza una interacción. Incorporar la voz no solo añade una capa adicional de estado para gestionar los componentes de la interacción de voz, sino que, idealmente, también permite reutilizar elementos de trabajos previos en otras modalidades. 

En este artículo explicamos cómo ElevenLabs Agents admite agentes externos y los patrones que permiten un control detallado de su integración. Estos mecanismos permiten a clientes aprovechar la orquestación de voz líder de ElevenLabs y, al mismo tiempo, conservar la propiedad total de su orquestación más amplia.

Componentes principales

ElevenLabs Agents

En su forma más sencilla, se puede acceder a un agente de ElevenLabs mediante un cliente WebSocket. La información que representa eventos del servidor y del cliente durante la conversación se transmite desde y hacia el agente como objetos JSON. Cuando el agente transcribe la voz del usuario, activa de inmediato una solicitud de generación. Admitimos la mayoría de los principales proveedores de modelos y permitimos a clientes aportar su propio LLM personalizado. Al incorporar un orquestador más complejo (agentes) para responder a las solicitudes de generación detrás del LLM personalizado, clientes deben asegurarse de que admita la API Chat Completions o Responses de OpenAI. Por suerte, esta especificación de formato de API es compatible fácilmente con la mayoría de los principales frameworks para crear agentes (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Una vez integrados, estos agentes suelen necesitar poder leer y actualizar su estado interno y externo en cualquier momento, independientemente del orquestador de voz tras el que se encuentren. Gestionarlo de forma eficaz garantiza la coherencia con los agentes existentes basados únicamente en texto. 

Gestión del estado

Por definición, los datos que un agente debe seguir para desenvolverse eficazmente en su entorno dependen en gran medida de la tarea. Para ElevenLabs Agents impulsados por un agente externo, resulta útil mantener el estado en varias categorías bien definidas.

El estado interno rige la dinámica de la conversación. Algunos ejemplos de elementos que se registran como parte del estado interno del agente son:

• El flujo conversacional actual, incluida la actividad de voz, las interrupciones y la identificación del hablante activo.
• Información específica de la aplicación obtenida del análisis de transcripciones en tiempo real, como intenciones, entidades o sentimiento detectados.
• El rastro de razonamiento, incluidos pensamientos intermedios, hipótesis e intentos previos de generar una solución.
• Parámetros de configuración y operativos, como sus objetivos activos, modo de funcionamiento y cualquier restricción temporal que guíe su comportamiento durante la interacción.

El estado externo, en cambio, se centra principalmente en los sistemas y las personas relevantes con los que el agente interactúa o sobre los que influye. Algunos ejemplos de elementos que se registran como parte del estado externo del agente son:

• El estado de otros usuarios o sistemas con los que interactúa, como sus objetivos actuales, disponibilidad o permisos.
• Herramientas y bases de conocimiento, por ejemplo, API, bases de datos o integraciones que pueden afectar a la capacidad de actuación del agente.
• Tareas y dependencias en curso que implican a actores o sistemas externos e influyen en los siguientes pasos del agente.

Describimos un patrón habitual para mantener esta información de forma fiable durante todo el ciclo de vida de la relación entre un agente y un usuario.

Componentes de la solución

Descripción general 

En esta sección abordamos los componentes de arquitectura y los detalles de implementación necesarios para integrar correctamente agentes externos complejos. La base de este enfoque es la capacidad de canalizar un identificador arbitrario, pero único, que representa una sesión a través de todos los servicios. En el caso de ElevenLabs Agents que utilizan LLM personalizados, esto puede hacerse simplemente pasando el identificador necesario como parámetro del LLM dentro del objeto extra body incluido como parte de las anulaciones de conversación al iniciar la llamada. De este modo, el identificador puede fluir desde el usuario, a través del agente de ElevenLabs, hasta el agente externo. 

Fíjate en el proxy con estado detrás del LLM personalizado. Este servicio, que normalmente no está presente, permite asignar solicitudes de generación individuales a identificadores arbitrarios que representan conexiones con el agente externo. La responsabilidad de implementar este servicio recae en desarrolladores del agente externo. En su forma más sencilla, el proxy gestiona conexiones representadas por identificadores únicos asignados a conversaciones de ElevenLabs o SID de llamadas (para telefonía). Las versiones más avanzadas, en cambio, pueden introducir una jerarquía en la asignación de conversaciones a relaciones con clientes más complejas que abarcan múltiples interacciones.

En estas configuraciones más avanzadas, el proxy mantiene identificadores adicionales que van más allá de una única solicitud vinculada a una única sesión posterior. En lugar de que cada identificador represente solo una conversación o SID de llamada, el proxy puede asociar un único identificador a varias interacciones relacionadas. Esto permite al sistema seguir los recorridos de clientes que pasan por distintos canales, reutilizar el contexto histórico y coordinar varias interacciones a la vez. Por ejemplo, una única asignación puede agrupar varias sesiones de chat web, una llamada de voz de seguimiento y un flujo de trabajo interno de asistencia bajo el mismo identificador lógico de cliente. El proxy puede entonces dirigir las solicitudes al identificador correcto basándose en reglas sencillas, al tiempo que conserva un estado unificado detrás del LLM personalizado. Esto permite interacciones de varios pasos más flexibles y persistentes gestionadas por el agente externo.

Intercambio de mensajes

Además de asignar correctamente las solicitudes de generación a entidades de orden superior, el proxy con estado puede admitir el intercambio bidireccional de mensajes con fuentes externas, como el frontend de la aplicación o un servicio de enrutamiento independiente, mediante solicitudes de API. En las aplicaciones en que sea necesario, ElevenLabs Agents no necesita saber que se están transmitiendo mensajes a otros servicios.  

Por ejemplo, suele ser útil que los agentes externos tengan visibilidad de la actividad de voz en curso para determinar si el usuario está hablando, durante cuánto tiempo y si deben tomar alguna medida de forma preventiva. Esta información puede obtenerse y utilizarse directamente transmitiendo puntuaciones procesadas de detección de actividad de voz (VAD) proporcionadas por ElevenLabs Agents como eventos de cliente recibidos a través del websocket de la conversación. Al recibir puntuaciones de ElevenLabs, la aplicación cliente puede reenviar eventos de cliente VAD al proxy con estado según los requisitos de la aplicación, asegurándose de incluir el identificador arbitrario de sesión en el mensaje. Es necesario que el proxy con estado implemente una lógica de asignación de solicitudes que identifique de forma óptima la conexión existente de la sesión. 

Este patrón puede ampliarse para admitir cualquier evento del cliente, siempre que pueda expresarse como un bloque de JSON. Sin embargo, también resulta útil exponer eventos originados en el propio agente. Un ejemplo habitual es el ciclo de vida de las llamadas a herramientas o las consultas a bases de conocimiento que representan operaciones en sistemas externos. Estos mecanismos son fundamentales para los agentes que las empresas crean hoy.

Al integrar agentes externos mediante un LLM personalizado, las funciones de llamada a herramientas y generación aumentada por recuperación (RAG) de ElevenLabs suelen omitirse en favor de la implementación propia del agente externo. Como resultado, la propiedad de estos componentes recae por completo en el proveedor del agente externo. Las aplicaciones siguen beneficiándose de tener visibilidad sobre la actividad de las herramientas, ya que les permite mostrar el progreso del agente y actualizar la experiencia del usuario final en consecuencia.

Para proporcionar esta visibilidad, el agente externo emite mensajes cada vez que se invocan herramientas, tanto para solicitudes como para respuestas. El proxy con estado reenvía estos mensajes a las aplicaciones cliente, que los gestionan mediante una cola de mensajes específica. Esto refleja los mecanismos utilizados por los eventos de cliente de ElevenLabs Agents y garantiza que las aplicaciones puedan realizar un seguimiento de cuándo el agente lee o modifica un sistema externo.

Por tanto, usar estos componentes principales y habilitar el intercambio bidireccional de mensajes entre el proxy y la aplicación cliente permite a clientes integrar agentes externos en ElevenLabs Agents para utilizar estrictamente la orquestación de voz que proporciona, a la vez que conservan la propiedad de todas las partes de la orquestación del LLM. 

Cómo se relaciona con el estado

Para admitir agentes externos complejos de forma eficaz, es necesario establecer una división clara de responsabilidades entre el proxy y el agente, especialmente en lo relativo a la gestión del estado. En este modelo, el proxy se encarga de mantener una tabla de interacciones relevantes, agrupadas según las necesidades de la aplicación, y de enrutar mensajes entre él y el agente mediante una lógica que sigue siendo sin estado. Por su parte, el agente externo debe gestionar y almacenar toda la información interna y externa sustancial que contribuye al estado general.

Aunque flexibilizar esta separación puede reducir aún más el trabajo de rehacer una solución existente, mantener un límite estricto suele dar lugar a resultados más sólidos y escalables a medida que crece el conjunto de tareas del agente.

De cara al futuro

A medida que las organizaciones maduran en la adopción de agentes con voz y sin voz, esperamos que se definan patrones para la información que estos agentes necesitan, lo que nos permitirá simplificar el desarrollo y la propiedad de los servicios descritos en este artículo. Mientras tanto, seguimos desarrollando soluciones para los requisitos que ya han surgido. Nuestro equipo de Forward Deployed Engineering colabora estrechamente con clientes para convertir estas necesidades emergentes en capacidades concretas de producto y garantizar que nuestras soluciones evolucionen a la par que las implementaciones reales.

Si ya trabajas con un agente y quieres habilitar la voz con ElevenLabs Agents sin renunciar a la propiedad de la orquestación de tu LLM, prueba este enfoque y cuéntanos qué te parece.