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

Los orquestadores de agentes de vanguardia son cada vez más capaces de manejar tareas complejas y operar en toda la suite de herramientas empresariales. Esto requiere una gestión diligente del estado de la aplicación, la conversación y el sistema. Para modalidades distintas a la voz, han surgido patrones comunes bajo el término general de ingeniería de contexto, que busca construir prácticas consistentes en torno al prompt del sistema de un agente a medida que avanza la interacción. Incorporar la voz no solo introduce una capa adicional de estado para gestionar los componentes de la interacción de voz, sino que idealmente también permite reutilizar artefactos de trabajos previos en otras modalidades.

En este post, describimos cómo ElevenLabs Agents apoyan a agentes externos y los patrones que permiten un control detallado sobre su integración. Estos mecanismos permiten a los clientes aprovechar la orquestación de voz de primera clase de ElevenLabs mientras mantienen la propiedad total de su orquestación más amplia.

Componentes principales

ElevenLabs Agents

En su forma más simple, un ElevenLabs Agent es accesible a través de un cliente Websocket. La información que representa eventos del servidor y del cliente en la conversación se transmite hacia y desde el agente como objetos JSON. Cuando el agente transcribe el discurso del usuario, activa de manera ávida una solicitud de generación. Soportamos la mayoría de los principales proveedores de modelos y permitimos a los clientes traer su propio Custom LLM. Al traer un orquestador más complejo (agentes) para responder a solicitudes de generación detrás del Custom LLM, los clientes deben asegurarse de que soporte la API de Chat Completions o Responses de OpenAI. Afortunadamente, esta especificación de formato de API es fácilmente soportada por la mayoría de los principales marcos de construcción de agentes (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...).

Una vez integrados, estos agentes a menudo requieren la capacidad de leer y actualizar su estado interno y externo en cualquier momento, independientemente del orquestador de voz que tengan detrás. Gestionar esto de manera efectiva asegura consistencia con agentes existentes solo de texto.

Gestión de estado

Por definición, los datos que un agente debe rastrear para navegar eficientemente su entorno son altamente específicos de la tarea. Para ElevenLabs Agents impulsados por un agente externo, es útil mantener el estado en unas pocas categorías bien definidas.

El estado interno gobierna la dinámica de la conversación. Ejemplos de elementos rastreados como parte del estado interno del agente incluyen:

• Flujo conversacional actual, incluyendo actividad de voz, interrupciones e identificación del hablante activo.
• Información específica de la aplicación derivada del análisis de transcripciones en tiempo real, como intenciones detectadas, entidades o sentimiento.
• Rastro de razonamiento, incluyendo pensamientos intermedios, hipótesis e intentos previos de generar una solución.
• Parámetros de configuración y operación, como sus objetivos activos, modo de operación y cualquier restricción temporal que guíe su comportamiento durante la interacción.

El estado externo, por otro lado, se centra principalmente en los sistemas y personas relevantes con los que el agente interactúa o influye. Ejemplos de elementos rastreados como parte del estado externo del agente incluyen:

• 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 APIs, bases de datos o integraciones que pueden afectar la capacidad del agente para actuar.
• Tareas en curso y dependencias que involucran actores o sistemas externos que influyen en los próximos pasos del agente.

Describimos un patrón común para mantener de manera confiable esta información a lo largo del ciclo de vida de la relación de un agente con un usuario.

Componentes de la solución

Visión general

En esta sección, cubrimos los componentes de arquitectura y detalles de implementación necesarios para integrar con éxito agentes externos complejos. En el núcleo de este enfoque está la capacidad de hacer proxy de un identificador arbitrario pero único que representa una sesión a través de todos los servicios. Para ElevenLabs Agents que usan LLMs personalizados, esto se puede hacer simplemente pasando el identificador requerido como un parámetro LLM dentro del objeto extra body pasado como parte de las modificaciones de la conversación durante la iniciación de la llamada. Hacer esto permite que el identificador fluya a través del ElevenLabs Agent desde el usuario hasta el agente externo.

Observa el proxy con estado detrás del LLM personalizado. Este servicio, que generalmente no está presente, nos permite mapear solicitudes de generación individuales a identificadores arbitrarios que representan conexiones con el agente externo. La implementación de este servicio está en manos de los desarrolladores del agente externo. En su forma más simple, el proxy gestiona conexiones representadas por identificadores únicos que mapean a conversaciones de ElevenLabs o SIDs de llamadas (para telefonía). Mientras que, versiones más avanzadas pueden introducir jerarquía en el mapeo de conversaciones a relaciones de clientes más intrincadas que abarcan múltiples interacciones.

En estas configuraciones más avanzadas, el proxy mantiene identificadores adicionales que van más allá de una sola solicitud vinculada a una sola sesión descendente. En lugar de que cada identificador represente solo una conversación o SID de llamada, el proxy puede asociar un solo identificador con múltiples interacciones relacionadas. Esto permite que el sistema siga los recorridos de los clientes que se mueven a través de canales, reutilice el contexto histórico y coordine varias interacciones a la vez. Por ejemplo, un solo mapeo puede agrupar múltiples sesiones de chat web, una llamada de seguimiento y un flujo de trabajo de soporte interno bajo el mismo identificador lógico de cliente. El proxy puede entonces enrutar solicitudes al identificador correcto basado en reglas simples mientras preserva un estado unificado detrás del LLM personalizado. Esto permite interacciones más flexibles y persistentes de múltiples pasos gestionadas por el agente externo.

Paso de mensajes

Más allá de mapear con éxito las solicitudes de generación a entidades de orden superior, el proxy con estado puede soportar el paso bidireccional de mensajes a fuentes externas como el frontend de la aplicación o un servicio de enrutador separado a través de solicitudes API. En aplicaciones donde esto es necesario, ElevenLabs Agents no requieren ser conscientes de que los mensajes se están pasando a otros servicios.

Por ejemplo, a menudo es útil que los agentes externos tengan visibilidad sobre la actividad de voz en curso, para que puedan determinar si el usuario está hablando, por cuánto tiempo y si deben tomar alguna acción de manera preventiva. Estos conocimientos pueden derivarse y actuarse directamente pasando puntuaciones de detección de actividad de voz (VAD) procesadas proporcionadas por ElevenLabs Agents como eventos del 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 basado en los requisitos de la aplicación asegurándose de que incluya el identificador de sesión arbitrario en el mensaje. Es necesario que el proxy con estado implemente lógica de mapeo de solicitudes que identifique óptimamente la conexión existente para la sesión.

Este patrón puede extenderse para acomodar cualquier evento del cliente, siempre que pueda expresarse como un bloque de JSON. Sin embargo, también es útil exponer eventos que se originan en el propio agente. Un ejemplo común involucra el ciclo de vida de llamadas a herramientas o consultas a bases de conocimiento que representan operaciones en sistemas externos. Estos mecanismos son fundamentales para los agentes que las empresas están construyendo hoy.

Al integrar agentes externos a través de un LLM personalizado, las funciones de llamada a herramientas y generación aumentada por recuperación (RAG) de ElevenLabs a menudo se omiten en favor de la propia implementación del agente externo. Como resultado, la propiedad de estos componentes recae completamente en el proveedor del agente externo. Las aplicaciones aún se benefician de la visibilidad en la actividad de 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. Estos mensajes son reenviados por el proxy con estado a aplicaciones cliente, que los manejan a través de una cola de mensajes dedicada. Esto refleja los mecanismos utilizados por los eventos del cliente de ElevenLabs Agents y asegura que las aplicaciones puedan rastrear cuando el agente lee o modifica un sistema externo.

Así, usar estos componentes principales y habilitar el paso bidireccional de mensajes entre el proxy y la aplicación cliente permite a los clientes integrar agentes externos dentro de ElevenLabs Agents para usar estrictamente la orquestación de voz que proporciona mientras retienen la propiedad sobre todas las partes de la orquestación del LLM.

Vinculándolo de nuevo al estado

Apoyar agentes externos complejos de manera efectiva requiere una clara división de responsabilidades entre el proxy y el agente, especialmente cuando se trata de la gestión del estado. En este modelo, el proxy es responsable de mantener una tabla de interacciones relevantes, agrupadas según las necesidades de la aplicación, y de enrutar mensajes entre sí y el agente usando lógica que permanece sin estado. A su vez, el agente externo debe manejar y almacenar todas las piezas sustantivas de información interna y externa que contribuyen al estado general.

Aunque relajar esta separación puede reducir aún más el retrabajo de una solución existente, mantener un límite estricto generalmente conduce a resultados más robustos y escalables a medida que crece el conjunto de tareas del agente.

Mirando hacia adelante

A medida que las organizaciones maduran en su adopción de agentes habilitados para voz y no voz, esperamos que los patrones para la información requerida por estos agentes se cristalicen, permitiéndonos simplificar el desarrollo y la propiedad de los servicios descritos en este post. Mientras tanto, seguimos construyendo para los requisitos que ya han surgido. Nuestro equipo de Forward Deployed Engineering está colaborando estrechamente con los clientes para traducir estas necesidades emergentes en capacidades de producto concretas y asegurar que nuestras soluciones evolucionen en sintonía con los despliegues del mundo real.

Si ya estás trabajando con un agente existente y buscas habilitar la voz con ElevenLabs Agents mientras mantienes la propiedad sobre tu orquestación de LLM, prueba este enfoque y ¡déjanos saber qué piensas!