Desvendando o Motor de Orquestração do ElevenAgent

ElevenAgents são alimentados por um motor de orquestração de baixa latência, criado especialmente para conversas em tempo real, adicionando menos de 100ms de atraso. Essa arquitetura combina o melhor das pesquisas da ElevenLabs com LLMs de ponta de provedores como OpenAI, Google e Anthropic, além de modelos open-source selecionados e hospedados pela ElevenLabs. Ao usar múltiplos modelos em diferentes etapas do pipeline de respostas, o agente garante conversas altamente responsivas e com entendimento de contexto. Aproveitando dinamicamente os pontos fortes de cada modelo em conjunto, conseguimos desempenho confiável e escalável em várias tarefas empresariais e cenários de conversação, otimizando o equilíbrio entre inteligência, velocidade e custo.

Neste artigo, explicamos como esses modelos trabalham juntos para entregar as principais capacidades que os agentes precisam para atuar em ambientes complexos, e, mais especificamente, quais modelos veem quais tokens e em que momento. O ponto central é o gerenciamento do histórico da conversa em diferentes pontos da interação. Vamos revisar como e onde o histórico da conversa é compartilhado para esclarecer seu papel na orquestração, tanto em fluxos independentes quanto em fluxos multiagente.

Agente independente

Começamos explorando o agente independente e seus componentes principais. É razoável considerar que o agente minimamente funcional tem um prompt de sistema, acesso a algumas ferramentas e uma base de conhecimento. Clientes devem preferir agentes independentes em vez de workflows quando o caso de uso exige pouca verificação de sequência de etapas ou quando é importante evitar silos de conhecimento entre agentes. Silos de conhecimento surgem quando certas ferramentas, documentos ou contexto histórico estão acessíveis para alguns subagentes, mas não para outros. Isso é inerente a workflows multiagente e traz um equilíbrio entre flexibilidade e determinismo.

Para agentes independentes na ElevenLabs, é importante entender como eles:

• Criam solicitações de geração de forma eficiente
• Buscam e incorporam documentos relevantes
• Geram e executam chamadas de ferramentas para informar as respostas do agente
• Entregam resultados para avaliação e coleta de dados

Construindo o contexto da conversa 

Uma conversa entre um cliente e um agente da ElevenLabs representa uma série de turnos, onde cada turno é composto por uma troca de mensagens entre as duas partes. Essa lista alternada de mensagens do agente e do usuário serve como ponto de partida para construir o contexto da conversa. Em cada turno, o LLM recebe solicitações de geração contendo uma série de mensagens alternadas entre agente e usuário, sendo uma mensagem a mais que o turno anterior. Naturalmente, essa série de mensagens começa com uma mensagem de sistema representando o prompt do agente.

O orquestrador da ElevenLabs reduz a latência percebida do LLM prevendo quando o usuário terminou de falar. Em alguns casos, isso pode resultar em múltiplas solicitações de geração para o LLM com o mesmo contexto de conversa em um único turno. Enquanto a orquestração otimiza a velocidade de resposta dos agentes, a qualidade da resposta depende tanto de como o conhecimento é acessado. À medida que os clientes avançam, normalmente começam a fundamentar as respostas dos agentes em uma combinação de documentação proprietária e conteúdo público. Há alguns anos, a geração aumentada por recuperação (RAG) se tornou o padrão para isso.Bases de Conhecimento do ElevenAgents aprimoram o RAG com uma arquitetura multimodelo otimizada, que detalhamos em um post anterior. Isso permite recuperar documentos de forma confiável mesmo quando a entrada mais recente do usuário é um acompanhamento, um reconhecimento de esclarecimento ou não contém uma pergunta explícita.

A recuperação, porém, é apenas uma das formas de interação dos agentes com sistemas externos.

Ações e busca de informações usando ferramentas

Agentes da ElevenLabs podem executar ações reais e buscar informações ao vivo durante a conversa por meio de um sistema flexível de ferramentas. Esse poder traz uma consideração importante de design: cada ferramenta habilitada aumenta o tamanho do prompt serializado, já que seu nome, descrição e esquema de parâmetros são incluídos junto com o prompt do sistema e o histórico da conversa. À medida que mais ferramentas são adicionadas, aumenta também a responsabilidade do modelo em escolher a sequência correta de ferramentas. No Agent Builder, a descrição da ferramenta explica o que ela faz e quais campos retorna. É essa informação que o modelo de linguagem usa para entender o contexto do uso. Uma vez definida, as condições específicas para acionar a ferramenta ficam no prompt do sistema do agente. Por exemplo:

• Descrição da ferramenta para lookup_order: “Recupera os detalhes do pedido de um cliente pelo ID do pedido. Retorna status do pedido, itens comprados, endereço de entrega e código de rastreamento.”
• Instrução do prompt do sistema: “Após verificar a identidade do cliente, chame a ferramenta lookup_order para buscar os detalhes do pedido.”

Essa separação permite que as definições de ferramentas sejam reutilizáveis entre agentes, enquanto o prompt do sistema de cada agente controla o momento exato em que a ferramenta é acionada. Para ajudar clientes a criar esses prompts de forma eficiente, oferecemos orientações detalhadas em nosso Guia de Prompt. Dentro desse framework, vários tipos de ferramentas podem ser definidos, principalmente:

• Ferramentas webhook que chamam APIs externas.
• Ferramentas client que enviam solicitações como eventos pelo websocket da conversa.
• Ferramentas de sistema para ações internas, como transferências de chamadas.
• Ferramentas MCP que conectam a servidores Model Context Protocol.

Sempre que um agente decide usar uma ferramenta, ele busca os detalhes necessários na conversa e envia uma solicitação para executá-la. Assim que a ferramenta retorna um resultado, esse resultado é adicionado à conversa para que o modelo possa se referir a ele naturalmente na próxima resposta. Se necessário, a saída da ferramenta também pode atualizar as informações armazenadas do agente como uma variável dinâmica. Essas informações são mantidas como pares chave-valor simples, extraídas da resposta da ferramenta usando mapeamentos pré-definidos. Uma vez definidas, essas variáveis podem ser usadas no prompt do sistema do agente, em parâmetros de ferramentas futuras e em condições de workflow. Esse ciclo de feedback dá aos agentes uma espécie de memória de trabalho que evolui conforme interagem.

Embora isso explique como as ferramentas se integram ao raciocínio do agente, o momento da execução delas também pode ser configurado. As ferramentas podem rodar em três modos de execução, cada um adequado a uma necessidade de conversa diferente. No Modo Imediato, a ferramenta é executada assim que o LLM solicita. Esse é o padrão para buscas rápidas, como checar o status de um pedido. Quando combinado com uma fala pré-ferramenta, o agente primeiro gera um breve reconhecimento como “Vou verificar isso para você” e retorna ao usuário enquanto a ferramenta roda em paralelo, minimizando o silêncio. Para ferramentas mais lentas, a plataforma estende automaticamente essas mensagens de preenchimento para acompanhar o tempo de espera. Já no Modo Pós-Ferramenta, a execução é adiada até o agente terminar de falar. Isso é essencial para ações com consequências reais, como transferir uma chamada, encerrar uma sessão ou enviar um pagamento. O usuário ouve todo o contexto, como “Vou transferir você para o setor de cobrança agora”, e pode interromper antes da ação ser realizada. O Modo Assíncrono executa a ferramenta totalmente em segundo plano, sem pausar a conversa. Esse modo é ideal para operações do tipo “disparar e esquecer”, como enviar um e-mail, acionar um workflow externo ou registrar dados, quando o agente não precisa usar o resultado na resposta.

Com a execução e orquestração definidas, o próximo passo é entender como medir o desempenho.

Medindo o desempenho

Após uma chamada com um Agent ser concluída, os clientes podem querer extrair partes da ligação para análise, armazenamento ou para determinar se a chamada foi bem-sucedida. É aí que entram a Coleta de Dados e os Critérios de Avaliação. A Coleta de Dados permite extrair informações estruturadas da transcrição da chamada para análise e agregação. Os clientes costumam exportar esses dados para o data lakehouse da empresa para relatórios ou enriquecimento de workflows. Por exemplo, um Agent de Vendas pode extrair automaticamente dados de um prospect para criar ou atualizar um lead no sistema de CRM. Já os Critérios de Avaliação determinam se uma chamada é considerada bem-sucedida. Se todos os critérios forem atendidos, a chamada é marcada como sucesso; caso contrário, é sinalizada como falha. Isso garante que as conversas sigam padrões definidos de qualidade e integridade, além de fornecer feedback rápido. Assim que a chamada termina e o webhook pós-chamada é acionado, o agente processa a transcrição finalizada, incluindo execuções de ferramentas e metadados, em um LLM junto com todos os pontos de coleta de dados e critérios de avaliação configurados. O modelo usa esse prompt combinado para determinar se cada critério foi atendido e para extrair os dados especificados para análise. Como o LLM interpreta essas configurações diretamente no prompt de entrada, é importante formatá-las de forma clara e consistente para que o modelo entenda e aplique corretamente. Por isso, recomendamos as seguintes práticas para escrever descrições de Critérios de Avaliação e Coleta de Dados.

Critérios de avaliação

1. Um objetivo claro por critério: uma frase ou bullet curto é melhor do que vários objetivos em um critério só.
2. Observável e baseado na transcrição: formule o objetivo de modo que sucesso/falha possa ser decidido pela transcrição (o que foi dito, o que o agente fez, o que o usuário pediu). Evite objetivos que dependam de contexto externo que o LLM não tem.
3. Resultados explícitos de sucesso/falha/desconhecido: o LLM já entende que para marcar como sucesso o objetivo deve ser atingido, como falha se não for, e como desconhecido se não der para saber pela transcrição. Por isso, o objetivo deve ser escrito de forma que “atingido” vs “não atingido” fique bem definido; se for ambíguo, o modelo pode tender para desconhecido ou classificar errado.
4. Seja conciso: às vezes, muitos critérios de avaliação são enviados juntos. Critérios longos podem gerar ruído e causar alucinações.
5. A linguagem importa: qualquer justificativa dada pelo LLM sobre se um critério foi atendido ou não será na mesma língua da descrição do critério, então é importante considerar isso.

Coleta de dados

1. Descreva exatamente o que extrair: a descrição é o principal sinal para o LLM. Explique o que o campo significa, em que situação deve ser preenchido e o que fazer quando não estiver claro (ex: “Deixe nulo se o cliente não informou uma data preferida”).
2. Combine com o tipo esperado: o valor fornecido pelo LLM sempre vai corresponder ao tipo de dado definido para o ponto de coleta (ex: booleano, string, inteiro etc). Então a descrição deve refletir isso. Por exemplo: “Extrair o número de itens solicitados” para inteiro, e “Sim/não se o cliente aceitou a oferta” para booleano.
3. Use enums sempre que possível: para tipo string, se o conjunto de valores for fixo, use enum no schema; isso limita o modelo e reduz saídas inválidas.
4. Um alvo de extração por item: Não coloque vários fatos não relacionados na descrição de um item; divida em itens separados para que cada chamada tenha um alvo de extração claro.
5. Mantenha as descrições curtas: As descrições podem ter algumas frases; não precisa de parágrafos longos. A transcrição já está na mensagem do usuário, então o schema + descrição curta é suficiente.

Atualmente, o LLM usado para essa etapa de avaliação e extração é fixo em um modelo de baixa latência para garantir processamento rápido. Em breve, esperamos oferecer opções para dar mais flexibilidade aos clientes.

A seguir, vamos focar em casos de uso que exigem orquestração estruturada, determinismo ou especialização em múltiplos papéis de conversa, onde os clientes podem usar Workflows.

Workflows

Workflows oferecem uma interface visual para criar fluxos de conversa complexos. No final, geram o objeto lógico usado pelo orquestrador para gerenciar múltiplos subagentes, ferramentas e transferências sob um identificador de agente independente. Workflows trazem componentes adicionais além dos já descritos para agentes independentes, incluindo como:

• Prompts de sistema e objetivos de conversa dos subagentes interagem.
• A passagem por diferentes pontos de transição no grafo é determinada.

Objetivos de conversa especializados

Workflows reaproveitam funcionalidades dos agentes independentes para garantir comportamentos consistentes durante toda a interação. Isso inclui elementos compartilhados como o prompt de sistema base, ferramentas principais e bases de conhecimento globais que devem estar sempre disponíveis, independentemente da etapa ativa do workflow. O prompt de sistema principal normalmente define o contexto global da conversa, tom esperado, restrições de segurança e qualquer instrução específica da marca ou do produto.

Sobre essa base compartilhada, Workflows introduzem subagentes especializados que atuam em um grafo direcionado. Cada subagente recebe um objetivo bem definido e complementa a configuração base com instruções adicionais de prompt, ferramentas e fontes de conhecimento relevantes apenas para sua função. Em vez de redefinir toda a configuração da conversa, os subagentes adicionam sua intenção ao agente base por meio de composição de prompt e extensão seletiva de contexto. O histórico da conversa é mantido entre transições de subagentes para garantir continuidade, mas cada subagente opera com uma visão propositalmente limitada do sistema. Bases de conhecimento e ferramentas são expostas de forma seletiva, criando silos claros que evitam vazamento de responsabilidades. Para reforçar esse isolamento, o objeto do orquestrador é reconstruído a cada transição como se fosse um agente independente. Isso garante que o estado do prompt, configuração e capacidades disponíveis do subagente ativo permaneçam totalmente determinísticos. Esse design permite que Workflows mantenham consistência global e, ao mesmo tempo, suportem especialização local, resultando em comportamento previsível, separação clara de responsabilidades e controle preciso sobre como contexto, conhecimento e ações são aplicados em cada etapa da interação.

Um dos mecanismos-chave que tornam esse controle possível é como as transições entre subagentes são gerenciadas.

Controlando transições de workflow com condições do LLM

Workflows avançam percorrendo um grafo direcionado de subagentes, onde as transições entre nós são controladas por condições explícitas. Essas condições determinam quando o controle deve passar de um subagente para outro e permitem que os workflows respondam à entrada do usuário, resultados de ferramentas e variáveis dinâmicas. As condições do grafo podem ser determinísticas ou avaliadas pelo LLM. Condições determinísticas, como transições incondicionais, checagens baseadas em variáveis dinâmicas ou resultados de ferramentas, oferecem garantias fortes sobre o fluxo de controle e são ideais para garantir progressão rígida no workflow. Já as condições baseadas em LLM permitem avaliação semântica de critérios em linguagem natural, como detectar intenção do usuário ou reconhecer quando uma informação específica foi fornecida.

É importante destacar que as condições do LLM são avaliadas fora do prompt do agente ativo e não influenciam o comportamento de geração do agente. Em vez disso, são avaliadas em paralelo pelo orquestrador com base no estado atual da conversa. Essa separação garante que a lógica de transição não contamine o prompt do agente nem afete como as respostas são geradas, mas ainda permite que os workflows aproveitem o raciocínio do LLM para percorrer o grafo de forma flexível. Combinando condições determinísticas e avaliadas pelo LLM, os workflows conseguem ser previsíveis e adaptáveis, usando transições determinísticas onde a precisão é crítica e transições baseadas em LLM onde é preciso interpretar o significado.

Quando a conversa avança para uma nova etapa, o sistema ativa uma versão do agente ajustada especificamente para aquele momento. Cada etapa opera com instruções focadas e acesso apenas ao conhecimento e ferramentas relevantes para sua responsabilidade. Por exemplo, uma etapa de reembolso pode acessar políticas de reembolso sem herdar contexto não relacionado de onboarding ou triagem. A movimentação entre etapas é controlada por condições de transição explícitas. Essas condições determinam quando a responsabilidade deve mudar e permitem decisões de roteamento naturais conforme a conversa evolui. Para manter a continuidade, a experiência do usuário permanece fluida entre as transições, com cada etapa herdando o contexto relevante da conversa sem expor os detalhes da passagem. Salvaguardas também monitoram as transições para evitar ciclos improdutivos, garantindo que o workflow permaneça estável e focado no objetivo.

Segurança e proteção

Para casos que exigem controles extras de segurança e proteção, os clientes podem contar com recursos adicionais do orquestrador.

Guardrails

Os Agents da ElevenLabs implementam guardrails de segurança por meio de um sistema configurável de moderação e alinhamento que avalia mensagens do usuário e do agente em tempo real. O conteúdo recebido é classificado em várias categorias de risco, incluindo conteúdo sexual, violência, assédio, ódio e autoagressão, cada uma com limites configuráveis de forma independente. Quando um guardrail é acionado, a conversa é encerrada imediatamente e o cliente recebe uma notificação clara do motivo. Isso garante que interações inseguras sejam bloqueadas cedo e de forma consistente, sem depender apenas de mitigação via prompt. Os guardrails funcionam fora da lógica do prompt do agente, oferecendo uma camada de proteção confiável que não pode ser burlada pelo modelo ou pelo usuário. Assim, os clientes podem ajustar a sensibilidade de segurança conforme seu domínio, mantendo a aplicação determinística em tempo real.

Gestão de dados em conformidade

Em algumas situações, quem fala pode compartilhar informações sensíveis com um agente, sujeitas a requisitos rigorosos de armazenamento e processamento, como dados médicos que exigem tratamento compatível com HIPAA. Para esses casos, oferecemos o Modo Zero Retenção (ZRM) no nível do Agent ou do Workspace. Quando ativado, todos os dados da chamada são processados apenas em memória e nunca gravados em armazenamento permanente. Após o término da chamada e do processamento, nenhuma informação é retida pela ElevenLabs. Assim, transcrições, gravações de áudio e análises não ficam disponíveis no Dashboard dos Agents, e essa política vale tanto para sistemas voltados ao cliente quanto para logs internos. Embora os dados não sejam retidos, eles são processados durante a chamada, e qualquer webhook pós-chamada configurado receberá os resultados, permitindo que o cliente armazene transcrições ou análises em seus próprios sistemas, se desejar.

Quando o ZRM está ativo, também garantimos que subprocessadores não retenham dados, restringindo os LLMs disponíveis a provedores com compromissos contratuais que proíbem treinamento ou retenção de dados do cliente; atualmente, isso inclui modelos do Google Gemini e Anthropic Claude. Clientes que desejam usar outro LLM sob ZRM podem fazê-lo assinando um acordo próprio com o provedor e configurando-o como LLM personalizado usando chaves de API cobertas por esse acordo. Como isso amplia o tratamento de dados além do nosso limite padrão de confiança, nossa equipe de Segurança precisa revisar e aprovar manualmente o caso antes de liberar. Embora o ZRM garanta que a ElevenLabs e subprocessadores não retenham dados da chamada, os clientes continuam responsáveis por garantir que quaisquer ferramentas externas ou webhooks usados pelo Agent estejam em conformidade com as exigências de retenção e regulamentação aplicáveis.

O que vem pela frente

Neste artigo, mostramos como os Agents da ElevenLabs gerenciam contexto de conversa, ferramentas, avaliação e workflows estruturados para entregar experiências confiáveis e em tempo real em escala. À medida que os clientes implantam agentes em ambientes cada vez mais complexos, seguimos ampliando a flexibilidade do nosso motor de orquestração, desde modelos de avaliação configuráveis e controles de transição mais ricos até maior visibilidade sobre composição de prompts e uso de tokens em cada etapa.

Nossa equipe de Forward Deployed Engineering está trabalhando lado a lado com os clientes para garantir que essas capacidades evoluam junto com as implantações reais. A próxima geração de Agents vai oferecer ainda mais transparência, determinismo e adaptabilidade, sem abrir mão da baixa latência que torna possível a conversa em tempo real.