Integrando agentes externos com a orquestração de voz dos ElevenLabs Agents

Padrões para integrar a orquestração de voz da ElevenLabs com agentes complexos e com estado

orange mountain on the right side and blue sky on the left

Orquestradores de agentes de ponta estão cada vez mais capazes de lidar com tarefas complexas e operar em toda a suíte de ferramentas empresariais. Isso requer um gerenciamento cuidadoso do estado de aplicação, conversa e sistema. Para modalidades além da voz, padrões comuns surgiram sob o termo guarda-chuva de engenharia de contexto, que visa construir práticas consistentes em torno do prompt do sistema de um agente à medida que a interação progride. Integrar a voz não só introduz uma camada adicional de estado para gerenciar componentes da interação de voz, mas idealmente também permite o reuso de artefatos de trabalhos anteriores em outras modalidades.

Neste post, descrevemos como os ElevenLabs Agents suportam agentes externos e os padrões que permitem um controle detalhado sobre sua integração. Esses mecanismos permitem que os clientes aproveitem a orquestração de voz de ponta da ElevenLabs enquanto mantêm total propriedade de sua orquestração mais ampla.

Componentes principais

ElevenLabs Agents

Na sua forma mais simples, um ElevenLabs Agent é acessível através de um cliente Websocket. Informações representando eventos de servidor e cliente na conversa passam para e do agente como objetos JSON. Quando o agente transcreve a fala do usuário, ele aciona rapidamente uma solicitação de geração. Suportamos a maioria dos principais provedores de modelos e permitimos que os clientes tragam seu próprio Custom LLM. Ao trazer um orquestrador mais complexo (agentes) para responder a solicitações de geração por trás do Custom LLM, os clientes devem garantir que ele suporte a API de Chat Completions ou Responses da OpenAI. Felizmente, essa especificação de formatação de API é facilmente suportada pela maioria dos principais frameworks de construção de agentes (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...).

Uma vez integrados, esses agentes frequentemente requerem a capacidade de ler e atualizar seu estado interno e externo a qualquer momento, independentemente do orquestrador de voz que estão por trás. Gerenciar isso de forma eficaz garante consistência com agentes existentes apenas de texto.

Gerenciamento de estado

Por definição, os dados que um agente deve rastrear para navegar eficientemente em seu ambiente são altamente específicos da tarefa. Para os ElevenLabs Agents alimentados por um agente externo, é útil manter o estado em algumas categorias bem definidas.

O estado interno governa a dinâmica da conversa. Exemplos de elementos rastreados como parte do estado interno do agente incluem:

  • Fluxo de conversa atual, incluindo atividade de voz, interrupções e identificação do falante ativo.
  • Insights específicos da aplicação derivados da análise de transcrição em tempo real, como intenções detectadas, entidades ou sentimento.
  • Rastro de raciocínio, incluindo pensamentos intermediários, hipóteses e tentativas anteriores de gerar uma solução.
  • Parâmetros de configuração e operacionais, como seus objetivos ativos, modo de operação e quaisquer restrições temporárias que guiam seu comportamento durante a interação.

O estado externo, por outro lado, foca principalmente em sistemas e indivíduos relevantes com os quais o agente interage ou influencia. Exemplos de elementos rastreados como parte do estado externo do agente incluem:

  • Status de outros usuários ou sistemas com os quais interage, como seus objetivos atuais, disponibilidade ou permissões.
  • Ferramentas e bases de conhecimento, por exemplo, APIs, bancos de dados ou integrações que podem afetar a capacidade do agente de agir.
  • Tarefas em andamento e dependências envolvendo atores ou sistemas externos que influenciam os próximos passos do agente.

Descrevemos um padrão comum para manter de forma confiável essas informações ao longo do ciclo de vida do relacionamento de um agente com um usuário.

Componentes da solução

Visão geral

Nesta seção, abordamos os componentes de arquitetura e detalhes de implementação necessários para integrar com sucesso agentes externos complexos. No centro dessa abordagem está a capacidade de proxyar um identificador arbitrário, mas único, representando uma sessão em todos os serviços. Para os ElevenLabs Agents usando LLMs personalizados, isso pode ser feito simplesmente passando o identificador necessário como um parâmetro LLM dentro do objeto extra body passado como parte das substituições de conversa durante a iniciação da chamada. Fazer isso permite que o identificador flua através do ElevenLabs Agent do usuário até o agente externo.

diagram describing the flow from user to elevenlabs websocket to custom llm to stateful proxy to external agent

Observe o proxy com estado por trás do LLM personalizado. Este serviço, que geralmente não está presente, nos permite mapear solicitações de geração individuais para identificadores arbitrários representando conexões com o agente externo. A propriedade da implementação deste serviço está nas mãos dos desenvolvedores do agente externo. Na sua forma mais simples, o proxy gerencia conexões representadas por identificadores únicos mapeando para conversas ou SIDs de chamadas da ElevenLabs (para telefonia). Enquanto versões mais avançadas podem introduzir hierarquia no mapeamento de conversas para relacionamentos de clientes mais intrincados que abrangem múltiplas interações.

Comparison of mapping ids for one to one versus one to many cases. In the case of one to many, there is a hierarchy grouping multiple conversations ids together.

Nessas configurações mais avançadas, o proxy mantém identificadores adicionais que vão além de uma única solicitação vinculada a uma única sessão downstream. Em vez de cada identificador representar apenas uma conversa ou SID de chamada, o proxy pode associar um único identificador a múltiplas interações relacionadas. Isso permite que o sistema siga jornadas de clientes que se movem entre canais, reutilize contexto histórico e coordene várias interações ao mesmo tempo. Por exemplo, um único mapeamento pode agrupar várias sessões de chat na web, uma chamada de voz de acompanhamento e um fluxo de trabalho de suporte interno sob o mesmo identificador lógico de cliente. O proxy pode então rotear solicitações para o identificador correto com base em regras simples, enquanto preserva um estado unificado por trás do LLM personalizado. Isso permite interações multi-etapas mais flexíveis e persistentes gerenciadas pelo agente externo.

Passagem de mensagens

Além de mapear com sucesso solicitações de geração para entidades de ordem superior, o proxy com estado pode suportar a passagem bidirecional de mensagens para fontes externas, como o frontend da aplicação ou um serviço de roteamento separado através de solicitações de API. Em aplicações onde isso é necessário, os ElevenLabs Agents não precisam estar cientes de que mensagens estão sendo passadas para outros serviços.

Por exemplo, muitas vezes é útil para agentes externos terem visibilidade sobre a atividade de voz em andamento, para que possam determinar se o usuário está falando, por quanto tempo e se deve tomar alguma ação preventivamente. Esses insights podem ser diretamente derivados e acionados passando pontuações de detecção de atividade de voz (VAD) processadas fornecidas pelos ElevenLabs Agents como eventos do cliente recebidos através do websocket de conversa. Ao receber pontuações da ElevenLabs, a aplicação cliente pode encaminhar eventos de cliente VAD para o proxy com estado com base nos requisitos da aplicação, garantindo que inclua o identificador de sessão arbitrário na mensagem. É necessário que o proxy com estado implemente lógica de mapeamento de solicitações que identifique de forma otimizada a conexão existente para a sessão.

Esse padrão pode ser estendido para acomodar qualquer evento do cliente, desde que possa ser expresso como um bloco de JSON. No entanto, também é útil expor eventos que se originam do próprio agente. Um exemplo comum envolve o ciclo de vida de chamadas de ferramentas ou consultas a bases de conhecimento que representam operações em sistemas externos. Esses mecanismos são fundamentais para os agentes que as empresas estão construindo hoje.

Ao integrar agentes externos através de um LLM personalizado, os recursos de chamada de ferramentas e geração aumentada por recuperação (RAG) da ElevenLabs são frequentemente ignorados em favor da própria implementação do agente externo. Como resultado, a propriedade desses componentes recai inteiramente sobre o provedor do agente externo. As aplicações ainda se beneficiam da visibilidade sobre a atividade das ferramentas, pois isso permite que elas mostrem o progresso do agente e atualizem a experiência do usuário final de acordo.

Para fornecer essa visibilidade, o agente externo emite mensagens sempre que ferramentas são invocadas, tanto para solicitações quanto para respostas. Essas mensagens são encaminhadas pelo proxy com estado para aplicações clientes, que as manipulam através de uma fila de mensagens dedicada. Isso espelha os mecanismos usados pelos eventos do cliente dos ElevenLabs Agents e garante que as aplicações possam rastrear quando o agente lê ou modifica um sistema externo.

Diagram showing the message passing flow between some frontend application and the stateful proxy bypassing the elevenlabs agent.

Assim, usar esses componentes principais e permitir a passagem bidirecional de mensagens entre o proxy e a aplicação cliente permite que os clientes integrem agentes externos dentro dos ElevenLabs Agents para usar estritamente a orquestração de voz que ele fornece, enquanto retêm a propriedade sobre todas as partes da orquestração do LLM.

Ligando de volta ao estado

Suportar agentes externos complexos de forma eficaz requer uma divisão clara de responsabilidades entre o proxy e o agente, especialmente quando se trata de gerenciamento de estado. Neste modelo, o proxy é responsável por manter uma tabela de interações relevantes, agrupadas de acordo com as necessidades da aplicação, e por rotear mensagens entre ele e o agente usando lógica que permanece sem estado. Por sua vez, o agente externo deve lidar e armazenar todas as peças substantivas de informações internas e externas que contribuem para o estado geral.

Embora relaxar essa separação possa reduzir ainda mais o retrabalho de uma solução existente, manter uma fronteira estrita geralmente leva a resultados mais robustos e escaláveis à medida que o conjunto de tarefas do agente cresce.

Olhando para o futuro

À medida que as organizações amadurecem em sua adoção de agentes habilitados para voz e não voz, esperamos que os padrões para as informações exigidas por esses agentes se cristalizem, permitindo-nos simplificar o desenvolvimento e a propriedade dos serviços descritos neste post. Enquanto isso, continuamos a construir para os requisitos que já surgiram. Nossa equipe de Engenharia Implantada Avançada está colaborando de perto com os clientes para traduzir essas necessidades emergentes em capacidades concretas de produto e garantir que nossas soluções evoluam em sintonia com as implantações no mundo real.

Se você já está trabalhando com um agente existente e deseja habilitar a voz com os ElevenLabs Agents enquanto retém a propriedade sobre sua orquestração de LLM, experimente esta abordagem e nos diga o que você acha!

Explore artigos da equipe ElevenLabs

ElevenLabs

Crie com o áudio IA da mais alta qualidade