Modelos em Cascata vs. Fundidos: Comparando as arquiteturas por trás de agentes conversacionais

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.

A arquitetura do agente ajuda a definir o quão natural, inteligente e consistente são suas respostas, além de influenciar se ele se comporta de forma previsível ao longo do tempo. Por exemplo, um agente com arquitetura baseada em fusão pode soar muito realista em conversas curtas, mas ter dificuldades para raciocinar ou manter a consistência em diálogos mais longos.

Na ElevenLabs, usamos uma arquitetura baseada em cascata, que conecta componentes especializados para reconhecimento de fala, raciocínio e geração de fala. Já o modelo Realtime da OpenAI adota uma abordagem baseada em fusão, consolidando essas etapas em uma única rede.

Neste post, mostramos as cinco principais arquiteturas de agentes conversacionais que existem hoje, explicando seus conceitos, vantagens, desvantagens e como as equipes escolhem entre elas de acordo com seus objetivos.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.

O que as equipes priorizam ao criar agentes

• 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 

Embora fatores como concorrência, integrações e qualidade de voz também sejam importantes, as dimensões acima podem ser mais diretamente influenciadas pela arquitetura do agente. As equipes mais bem-sucedidas adaptam a arquitetura para otimizar esses pontos conforme o uso desejado.

Arquiteturas baseadas em cascata são compostas por componentes especializados conectados em sequência: , um Large Language Model e Transformar Texto em Áudio. Cada etapa pode ser otimizada, testada e atualizada de forma independente.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.

Essa modularidade permite que as equipes usem os LLMs mais avançados para melhorar o raciocínio, apliquem limites claros na camada de texto e controlem com precisão como o agente fala usando TTS contextual. O principal ponto negativo é que arquiteturas em cascata tendem a perder mais informações prosódicas — como entonação, ritmo e emoção — porque a fala é convertida em texto antes de ser gerada novamente. Esses elementos podem ser parcialmente recuperados com modelagem explícita, mas não são capturados de forma tão natural quanto nas abordagens fundidas. Outros aspectos, como latência e turnos de fala, geralmente podem ser otimizados para alcançar desempenhos semelhantes em ambas as abordagens.

Já as abordagens fundidas combinam essas etapas em um único modelo multimodal. O áudio entra e sai, com reconhecimento de fala, raciocínio e geração acontecendo dentro da mesma rede. À 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.”

Esse design permite que arquiteturas baseadas em fusão preservem e reproduzam a prosódia de forma mais eficaz, já que o modelo processa pronúncia e entonação diretamente. Porém, modelos fundidos são mais difíceis de testar e controlar, pois não expõem saídas intermediárias. Eles também costumam usar LLMs mais leves, o que limita o raciocínio e o uso de ferramentas em comparação com abordagens em cascata que podem usar os modelos mais avançados disponíveis.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.

As cinco arquiteturas possíveisvariá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.

1. Cascata Básica

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

Em arquiteturas em cascata básicas, o áudio é transcrito, o LLM gera uma resposta em texto e o TTS fala exatamente as palavras recebidas. Como cada etapa trabalha apenas com texto, as equipes têm total visibilidade e controle. Limites podem ser aplicados na camada de texto, chamadas de ferramentas e integrações de API são feitas diretamente pelo LLM, e fluxos determinísticos podem direcionar conversas e aplicar regras de negócio de forma mais previsível.

Por outro lado, o agente não reconhece nuances da fala como tom, ritmo e emoção, o que pode deixar a conversa menos natural.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.

Possíveis usos incluem:

1. Atendimento ao cliente uma frase ou bullet curto é melhor do que vários objetivos em um critério só.
2. Assistentes de vendas 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. Recepcionistas com IA 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. NPCs para entretenimento e jogos às vezes, muitos critérios de avaliação são enviados juntos. Critérios longos podem gerar ruído e causar alucinações.
5. Substituição de URA 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.

2. Cascata Avançada

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.

Arquiteturas em cascata avançadas trazem o TTS contextual, onde o LLM decide não só o que dizer, mas também como dizer, enviando instruções como "diga isso de forma tranquilizadora" ou "responda com ênfase" para o modelo de TTS. O agente fala com tom e estilo mais realistas, mantendo os mesmos limites, fluxos determinísticos, uso de ferramentas e auditabilidade do sistema em cascata básico.

Essa é a abordagem usada no

Possíveis usos incluem versões mais expressivas de:

Atendimento ao cliente 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

Algumas arquiteturas em cascata enviam características acústicas (como pronúncia, emoção e tom) da fala original diretamente para o LLM como embeddings. Assim, a arquitetura preserva mais da intenção do usuário, mantendo o TTS modular. O uso de ferramentas e limites ainda é possível, mas o bloco fundido de ASR+LLM é mais difícil de auditar do que uma transição limpa de texto, e o LLM não pode ser trocado com tanta facilidade quanto em um modelo em cascata.

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.

4. Fundido Sequencial

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

Em arquiteturas fundidas sequenciais, um único modelo multimodal faz reconhecimento, raciocínio e geração de fala. Operando um turno por vez, o modelo escuta até o usuário terminar e então gera o áudio diretamente. Ao processar o áudio de ponta a ponta, essas arquiteturas capturam naturalmente sinais como pronúncia, ritmo e entonação, resultando em falas mais fluidas e expressivas.

Por outro lado, é mais difícil aplicar limites sem uma camada de texto, o uso de ferramentas é limitado por núcleos de raciocínio mais leves e a visibilidade é reduzida sem saídas intermediárias claras.

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

5. Fundido Duplex

Guardrails

Em arquiteturas fundidas duplex, o modelo processa entrada e saída ao mesmo tempo. Isso pode gerar conversas com fluxo mais natural e sobreposição de fala, especialmente em diálogos curtos, mas também traz bastante complexidade. É mais difícil aplicar limites, interrupções e sobreposição de fala podem causar erros, e a visibilidade é mínima em comparação com arquiteturas em cascata.

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.

Como escolher a arquitetura ideal para seu caso de uso

Não existe uma arquitetura única que sirva para todos os agentes conversacionais. Cada variante tem pontos fortes e equilíbrios, desde a previsibilidade e controle dos modelos em cascata até a prosódia natural dos modelos fundidos.

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.