Integrando agentes externos com a orquestração de voz dos ElevenLabs Agents
- Escrito por
- Nicolas Bernier
- Publicado
- Última atualização
OuvirOuça este artigo
Orquestradores de agentes de ponta estão cada vez mais capazes de lidar com tarefas complexas e operar em todo o conjunto de ferramentas empresariais. Isso exige uma gestão cuidadosa do estado da aplicação, da conversa e do sistema. Para modalidades além da voz, surgiram padrões comuns sob o termo abrangente de engenharia de contexto, que busca estabelecer práticas consistentes em torno do prompt de sistema de um agente à medida que uma interação avança. Adicionar voz não só introduz uma camada extra de estado para gerenciar os componentes da interação por voz, como também, idealmente, permite reutilizar artefatos de trabalhos anteriores em outras modalidades.
Neste post, mostramos como ElevenLabs Agents oferece suporte a agentes externos e os padrões que permitem um controle detalhado sobre a integração deles. Esses mecanismos permitem que os clientes aproveitem a orquestração de voz líder de mercado da ElevenLabs, mantendo total controle sobre sua orquestração mais ampla.
Componentes principais
ElevenLabs Agents
Em sua forma mais simples, um agente da ElevenLabs é acessível por meio de um cliente WebSocket. Informações que representam eventos do servidor e do cliente na conversa são transmitidas de e para o agente como objetos JSON. Quando o agente transcreve a fala do usuário, ele aciona imediatamente uma solicitação de geração. Oferecemos suporte à maioria dos principais provedores de modelos e permitimos que os clientes usem seu próprio LLM personalizado. Ao usar um orquestrador mais complexo (agentes) para responder a solicitações de geração por trás do LLM personalizado, os clientes precisam garantir que ele ofereça suporte à API Chat Completions ou Responses da OpenAI. Felizmente, essa especificação de formatação de API é facilmente compatível com os principais frameworks de criação de agentes (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...).
Depois de integrados, esses agentes geralmente precisam conseguir ler e atualizar seu estado interno e externo a qualquer momento, independentemente do orquestrador de voz por trás deles. Gerenciar isso de forma eficaz garante consistência com os agentes existentes que usam apenas texto.
Gerenciamento de estado
Por definição, os dados que um agente precisa acompanhar para navegar pelo ambiente com eficiência são altamente específicos de cada tarefa. Para o ElevenLabs Agents com tecnologia de um agente externo, é útil manter o estado em algumas categorias bem definidas.
O estado interno controla a dinâmica da conversa. Exemplos de elementos acompanhados como parte do estado interno do agente incluem:
- Fluxo atual da conversa, incluindo atividade de voz, interrupções e identificação do participante ativo.
- Insights específicos da aplicação derivados da análise de transcrições em tempo real, como intenções, entidades ou sentimentos detectados.
- Rastro de raciocínio, incluindo pensamentos intermediários, hipóteses e tentativas anteriores de gerar uma solução.
- Parâmetros de configuração e operação, como objetivos ativos, modo de operação e quaisquer restrições temporárias que orientem seu comportamento durante a interação.
Já o estado externo se concentra principalmente em sistemas e pessoas relevantes com os quais o agente interage ou sobre os quais exerce influência. Exemplos de elementos acompanhados como parte do estado externo do agente incluem:
- Status de outros usuários ou sistemas com os quais ele interage, como objetivos atuais, disponibilidade ou permissões.
- Ferramentas e bases de conhecimento, como APIs, bancos de dados ou integrações que podem afetar a capacidade de ação do agente.
- Tarefas em andamento e dependências que envolvem participantes ou sistemas externos e influenciam os próximos passos do agente.
Apresentamos um padrão comum para manter essas informações de forma confiável durante todo o ciclo de vida da relação entre um agente e um usuário.
Componentes da solução
Visão geral
Nesta seção, abordamos os componentes de arquitetura e os detalhes de implementação necessários para integrar agentes externos complexos com sucesso. No centro dessa abordagem está a capacidade de fazer proxy de um identificador arbitrário, mas único, que representa uma sessão entre todos os serviços. No caso do ElevenLabs Agents que usam LLMs personalizados, isso pode ser feito simplesmente passando o identificador necessário como um parâmetro do LLM no objeto extra body transmitido como parte das substituições da conversa durante o início da chamada. Isso permite que o identificador percorra o agente da ElevenLabs, do usuário até o agente externo.

Observe o proxy com estado por trás do LLM personalizado. Esse serviço, que geralmente não está presente, permite mapear solicitações individuais de geração para identificadores arbitrários que representam conexões com o agente externo. A responsabilidade pela implementação desse serviço é dos desenvolvedores do agente externo. Em sua forma mais simples, o proxy gerencia conexões representadas por identificadores únicos, mapeados para conversas da ElevenLabs ou SIDs de chamadas (para telefonia). Já versões mais avançadas podem introduzir uma hierarquia no mapeamento de conversas para relações mais complexas com os clientes, abrangendo várias interações.

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 várias interações relacionadas. Isso permite que o sistema acompanhe jornadas de clientes que transitam entre canais, reutilize o 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 workflow interno de suporte sob o mesmo identificador lógico de cliente. Em seguida, o proxy pode encaminhar solicitações ao identificador correto com base em regras simples, preservando um estado unificado por trás do LLM personalizado. Isso permite interações de várias etapas mais flexíveis e persistentes, gerenciadas pelo agente externo.
Troca de mensagens
Além de mapear com sucesso solicitações de geração para entidades de nível superior, o proxy com estado pode oferecer suporte à troca bidirecional de mensagens com fontes externas, como o frontend da aplicação ou um serviço de roteamento separado, por meio de solicitações de API. Em aplicações nas quais isso é necessário, o ElevenLabs Agents não precisa saber que mensagens estão sendo transmitidas para outros serviços.
Por exemplo, muitas vezes é útil que agentes externos tenham visibilidade da atividade de voz em andamento, para determinar se o usuário está falando, por quanto tempo e se devem tomar alguma ação antecipadamente. Esses insights podem ser diretamente obtidos e usados ao transmitir as pontuações processadas de detecção de atividade de voz (VAD) fornecidas pelo ElevenLabs Agents como eventos do cliente recebidos pelo WebSocket da conversa. Ao receber pontuações da ElevenLabs, a aplicação cliente pode encaminhar eventos de cliente de VAD ao proxy com estado de acordo com os requisitos da aplicação, garantindo que a mensagem inclua o identificador arbitrário da sessão. É necessário que o proxy com estado implemente uma lógica de mapeamento de solicitações que identifique de forma ideal 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 originados no próprio agente. Um exemplo comum envolve o ciclo de vida de chamadas de ferramentas ou consultas à base de conhecimento que representam operações em sistemas externos. Esses mecanismos são fundamentais para os agentes que as empresas estão desenvolvendo hoje.
Ao integrar agentes externos por meio de um LLM personalizado, os recursos de chamada de ferramentas e geração aumentada por recuperação (RAG) da ElevenLabs costumam ser ignorados em favor da implementação do próprio agente externo. Como resultado, a responsabilidade por esses componentes fica inteiramente com o provedor do agente externo. As aplicações ainda se beneficiam da visibilidade sobre a atividade das ferramentas, pois isso permite mostrar o progresso do agente e atualizar a experiência do usuário final de acordo.
Para oferecer 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 às aplicações cliente, que as processam por uma fila de mensagens dedicada. Isso reflete os mecanismos usados pelos eventos de cliente do ElevenLabs Agents e garante que as aplicações possam acompanhar quando o agente lê ou modifica um sistema externo.

Assim, usar esses componentes principais e permitir a troca bidirecional de mensagens entre o proxy e a aplicação cliente permite que os clientes integrem agentes externos ao ElevenLabs Agents para usar estritamente a orquestração de voz fornecida, mantendo a responsabilidade sobre todas as partes da orquestração do LLM.
Relacionando isso ao estado
Oferecer suporte eficaz a agentes externos complexos exige uma divisão clara de responsabilidades entre o proxy e o agente, especialmente no gerenciamento de estado. Nesse 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 uma lógica sem estado. Por sua vez, o agente externo deve processar e armazenar todas as informações internas e externas relevantes que contribuem para o estado geral.
Embora flexibilizar essa separação possa reduzir ainda mais o retrabalho em uma solução existente, manter um limite rígido 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 na adoção de agentes habilitados para voz e sem voz, esperamos que os padrões para as informações exigidas por esses agentes se consolidem, permitindo simplificar o desenvolvimento e a responsabilidade pelos serviços descritos neste post. Enquanto isso, continuamos desenvolvendo para os requisitos que já surgiram. Nossa equipe de Engenharia Forward Deployed trabalha em estreita parceria com os clientes para transformar essas necessidades emergentes em recursos concretos de produto e garantir que nossas soluções evoluam em sintonia com implementações do mundo real.
Se você já trabalha com um agente existente e quer habilitar a voz com o ElevenLabs Agents mantendo a responsabilidade sobre sua orquestração de LLM, experimente essa abordagem e conte para nós o que achou!
Nicolas trabalha na equipe de Engenharia Implantada da ElevenLabs, colaborando com clientes para levar seus agentes à produção. Anteriormente, passou quatro anos na AWS, focando em indústrias regulamentadas e no setor público.



