Como construir agentes de voz duradouros: lições aprendidas com engenharia em campo

Para a maioria das organizações, as soluções pontuais para a área de suporte sempre foram avaliadas pela capacidade de evitar atendimentos. Ou seja, reduzir o volume de chamadas e minimizar as interações com agentes humanos. Mas evitar atendimento não significa resolver o problema, e é nessa diferença que a experiência do cliente se perde. Para fechar essa lacuna, os agentes precisam ter acesso não só aos dados, mas também aos sistemas necessários para agir. Assim, eles podem processar reembolsos, orientar clientes durante uma compra e transferir para um agente humano com todo o contexto quando necessário. Isso permite que empresas lidem com interações em grande escala, reduzindo de forma significativa a carga das equipes de suporte humano e melhorando a experiência de ambos os lados da chamada.implantação recente com a Revolut, uma fintech que atende 70 milhões de clientes no mundo todo, isso resultou em uma redução de 8x no tempo de resolução e uma taxa de sucesso de 99,7% nas chamadas.

Mudanças desse porte precisam ser feitas de forma iterativa, alinhadas à missão da empresa e com apoio forte da liderança. No lado técnico, trabalhar em ambientes não estruturados traz riscos que precisam ser bem gerenciados. Dar a um agente a capacidade de agir no sistema de CRM, modificar pedidos no ponto de venda ou escalar casos exige um modelo de governança tão importante quanto o modelo de IA em si. O foco deixa de ser se o agente consegue executar tarefas reais, e passa a ser quais mecanismos garantem que isso seja feito com segurança e de forma repetível.

Neste artigo, compartilhamos nossa experiência sobre o que faz um agente ser bem-sucedido, desde a primeira implantação até a escala em toda a operação de atendimento ao cliente.

Implantar agentes vs. implantar software

Antes de aprofundar na construção de agentes, vale comparar a implantação de agentes de voz com a de softwares tradicionais, algo que empresas já fazem há décadas. Por esse olhar, os agentes se dividem em dois componentes: software tradicional e orquestrador central.

Software:

Software: observabilidade e governança

Orquestrador central

Os componentes do Orquestrador Central são naturalmente mais difíceis de prever, mas determinam o desempenho do agente em tempo real, tanto na qualidade das respostas quanto na latência percebida. Diferente do software tradicional, esses componentes operam sobre linguagem natural e áudio, onde o espaço de entrada é praticamente ilimitado e pequenas mudanças na frase, contexto, ruído de fundo ou comportamento do usuário podem gerar resultados bem diferentes ao longo do tempo. Isso faz com que os testes convencionais não sejam suficientes: um agente pode ir muito bem em centenas de testes e ainda assim falhar em produção de formas difíceis de antecipar.controle de versões, testes A/B, telefonia e configuração da primeira mensagem, entre outros. Esses componentes mudam pouco ou nada após a implantação, tornando seu comportamento altamente previsível. Com boas práticas de engenharia, as empresas conseguem evoluir rapidamente esses recursos e acompanhar o desempenho em produção por meio de métricas, rastreamentos e logs. Melhorias de latência nessa camada seguem padrões conhecidos: cache, pool de conexões, escalabilidade de infraestrutura e otimização de protocolos são estratégias confiáveis com resultados previsíveis.

A latência nessa camada também é menos previsível, pois depende do tempo de inferência do modelo, inserção de artefatos sonoros, cadeias de chamadas de ferramentas e da variabilidade natural de sistemas generativos. Gerenciar bem esses componentes exige uma disciplina diferente, baseada em frameworks de avaliação, monitoramento em produção e disposição para iterar continuamente com base em dados reais de conversas, e não só em hipóteses prévias à implantação.

Essa diferença define como as organizações devem adotar a tecnologia: comece por casos de uso relevantes para o negócio, mas de baixo risco, e só escale conforme a confiança no sistema aumenta.

Ciclo de lançamento

Escolhendo os primeiros casos

Para equipes que estão começando a adotar agentes de voz, escolher os primeiros casos certos é uma das decisões mais importantes. E isso tem menos a ver com tecnologia do que muitos imaginam. Equipes que conseguem resultados rápidos e evitam ficar presas em provas de conceito geralmente têm algo em comum: conseguem responder com clareza às perguntas abaixo.

Para equipes que estão começando a usar agentes de voz, escolher bem os primeiros casos é uma das decisões mais importantes. E isso tem menos a ver com tecnologia do que parece. Times que conseguem resultados rápidos e evitam ficar presos em provas de conceito geralmente têm algo em comum: sabem responder claramente às perguntas abaixo.

• Como esse caso de uso gera valor de negócio mensurável? O melhor caso para começar não é o mais interessante tecnicamente, mas o que tem mais chance de impactar um resultado que a empresa já valoriza. Isso pode ser impacto em receita, redução de custos, satisfação do cliente ou outras métricas que a liderança já acompanha. Sem essa ligação direta com o negócio, fica difícil justificar os ciclos de iteração necessários para acertar o agente, e o projeto pode perder força antes de mostrar resultado.
• Está claro para o usuário qual é o objetivo e o escopo do agente?Ambiguidade de escopo é uma das principais causas de desvio entre desenvolvimento e produção. Usuários que não entendem o que o agente pode ou não fazer vão testar limites de formas que os testes não previram. Um agente bem definido já deixa claro o que faz desde a primeira mensagem e lida com pedidos fora do escopo de forma adequada.
• Como são as boas e más interações, e é possível transformá-las em critérios de avaliação concretos?Uma boa interação não é só quando o agente conclui a tarefa, mas quando o usuário se sente ouvido, a escalada acontece no momento certo e o resultado está alinhado ao objetivo do negócio. Os critérios de avaliação se dividem em duas categorias: métricas quantitativas capturadas pela plataforma, como taxa de conclusão de tarefas e de escalada, e critérios baseados na análise da conversa. Definir esses critérios desde o início dá um objetivo claro para a equipe. Eles também servem como limite natural para o lançamento. Quando o agente atinge os critérios de avaliação de forma consistente e as métricas estão estáveis, é hora de ir para produção. Sem critérios definidos, a decisão vira julgamento subjetivo.
• Quais são os trade-offs entre desempenho e controle, e qual é mais importante neste momento?Quanto mais autonomia o agente tem, mais natural e flexível fica a interação, mas também aumenta o risco de sair dos limites validados. Um controle mais rígido, com prompts restritos e lógica de escalada mais dura, reduz esse risco, mas pode deixar o agente engessado. Nenhum dos extremos é ideal. Empresas que restringem demais acabam com um IVR sofisticado. As que liberam cedo demais criam demandas de suporte que superam os ganhos. Entender o equilíbrio em cada etapa vai definir a configuração do modelo, a lógica de escalada e quanto do conhecimento do agente fica no prompt ou em fontes externas/estruturadas.

Definindo a base da primeira versão

Ao partir para a execução, as equipes podem usar metodologias quase tão antigas quanto o próprio software. O Desenvolvimento Orientado a Testes (TDD) serve de base para manter os agentes alinhados às métricas principais durante toda a construção.

Na execução, as equipes podem usar metodologias quase tão antigas quanto o próprio software. O Test Driven Development (TDD) serve de base para manter o agente alinhado às métricas principais durante todo o desenvolvimento.

Com um conjunto inicial de testes, o desenvolvimento do agente começa pelo prompt do sistema. É aqui que se definem as regras, o tom e a abordagem do agente: o que ele deve ou não fazer e como agir nos limites do seu papel. Um prompt bem elaborado é tão importante na estrutura quanto no conteúdo. Separar instruções em seções claras, agrupar orientações relacionadas e evitar frases condicionais faz diferença para o comportamento consistente do agente. Nessa etapa, costumamos voltar ao guia de prompts.Testes do Agente, que verificam repetidamente comportamentos esperados do agente. Os critérios são melhor definidos a partir da análise de chamadas reais. Os testes começam com um conjunto inicial de comportamentos esperados e vão sendo ampliados conforme surgem novos casos e exceções.

Junto com o prompt do sistema, são configurados os componentes principais do agente: o LLM, o modelo de transformar texto em áudio (TTS) e a voz. A escolha do LLM é um equilíbrio entre latência e desempenho: modelos otimizados para velocidade geralmente sacrificam um pouco de capacidade de raciocínio, e vice-versa. Para TTS, a escolha depende do que o caso de uso mais exige, seja entrega expressiva, baixa latência ou suporte multilíngue. Já a voz é uma decisão tanto de marca quanto técnica. Ela define como a organização será percebida por cada pessoa que liga, tornando essa escolha relevante tanto para equipes de marketing quanto para engenheiros. Por isso, a seleção da voz pode acontecer em paralelo ao desenvolvimento, sem ser um gargalo no início ou no fim. O ElevenAgents oferece acesso a mais de 10.000 vozes, e se nenhuma servir, as equipes podem clonar ou criar a própria.

A partir daí, os agentes podem ser estendidos opcionalmente com uma Base de Conhecimento,

Com essas bases prontas, o agente está preparado para ser testado.Base de Conhecimento, ferramentas e configurações de canais. Cada adição traz novas capacidades, mas também aumenta a superfície de testes. Seja integração com telefonia, acesso a bancos de dados externos ou a possibilidade de agir em nome do cliente, essas decisões devem ser testadas contra os critérios de avaliação antes de ampliar o escopo. Ao adicionar ferramentas, o prompt do sistema e a descrição das ferramentas orientam explicitamente quando e como usá-las, garantindo uso consistente e no contexto certo.

Rumo à prontidão para produção

Com os testes e critérios de avaliação definidos na fase inicial rodando sobre o agente construído, o desenvolvimento vira um ciclo curto: adicionar mais testes, identificar falhas, atualizar o prompt do sistema ou a configuração e testar novamente. A maioria das falhas nessa etapa não é do modelo, mas sim do prompt. Uma instrução que parecia clara isoladamente pode ser ambígua durante a conversa real. Casos de exceção surgem e não estavam previstos no conjunto inicial de testes. Cada um vira um novo teste de Próxima Interação, criado a partir da própria conversa. A resposta para quando parar de iterar é objetiva: quando o agente atinge os critérios de avaliação de forma consistente em várias execuções e as métricas da plataforma, como taxa de conclusão e de escalada, estão estáveis dentro dos limites aceitáveis. Por isso é tão importante definir esses critérios antes de construir. Sem eles, a prontidão vira julgamento subjetivo e o objetivo final nunca chega.

Na prática, a maioria das equipes percebe que um pequeno conjunto de padrões de falha recorrentes responde pela maior parte dos problemas. Os mais comuns são: ambiguidade no prompt, quando o agente recebe instruções conflitantes ou pouco claras e age de forma imprevisível; uso incorreto de ferramentas, quando o agente aciona uma ferramenta no contexto errado ou deixa de acionar quando deveria; e desvio na escalada, quando o agente escala rápido demais ou segura conversas que já deveria ter passado adiante. Cada um desses casos tem solução no próprio prompt: ajustar a instrução, adicionar um exemplo explícito ou mudar o limite de escalada geralmente resolve. O risco está em não identificar esses problemas antes do lançamento.

O erro mais comum das equipes é tratar um conjunto de testes aprovado como garantia, e não como sinal. Um conjunto que cobre só o caminho ideal vai passar fácil, mas não significa muito. Cobertura de recusas, mudanças de rumo no meio da conversa, entradas ambíguas e interações com muitas ferramentas é o que dá peso aos resultados. Da mesma forma, equipes que pulam testes de simulação e confiam só em testes de turno perdem falhas que só aparecem em conversas completas, como perda de contexto ou erros que se acumulam ao longo da chamada. Quando os padrões de falha recorrentes são resolvidos e o agente lida bem com os casos de exceção, mesmo que não perfeitamente, o valor de continuar iterando em staging diminui. A partir daí, o sinal mais valioso vem das conversas reais.

Ir para produção não significa que a iteração acabou. Significa que o aprendizado passa dos testes sintéticos para as transcrições reais. Os critérios de avaliação que definiram o lançamento viram a base para medir o desempenho ao vivo, e o ciclo continua a partir daí.

Ciclos de feedback, avaliação e quando parar de iterar

Depois que os testes estão definidos e rodando, as lacunas no processo ficam visíveis rapidamente. Com a

A disciplina mais importante nessa fase é validar as mudanças, não só presumir que funcionam. Uma correção que resolve um problema pode criar outro sem ser percebida. O ElevenAgents oferece controle de versões, permitindo que as equipes testem novas versões com uma pequena parcela dos usuários antes de liberar para todos. Assim, é possível confirmar se as melhorias realmente trazem resultados ou só mudam o tipo de falha.

O que pode dar erradocontrole de versões, permitindo testar novas versões com uma pequena parte dos usuários antes de liberar para todos. Assim, é possível confirmar se as melhorias realmente melhoram o resultado, em vez de só mudar o tipo de falha.

O erro mais grave nessa etapa é pular os lançamentos em etapas e aplicar mudanças direto para todos os usuários. Sem lançamentos graduais, você perde a capacidade de isolar o impacto de cada alteração e, em escala, fica quase impossível entender o que realmente está melhorando ou piorando as métricas da plataforma. Tratar toda a base de usuários como ambiente de teste não é só arriscado; elimina a visibilidade necessária para tomar decisões seguras no futuro.

Além da estratégia de lançamento, há outros dois riscos importantes. O primeiro é dar peso demais para falhas recentes. Quando uma conversa de destaque dá errado, é natural querer corrigir imediatamente, mas mudanças reativas no prompt sem rodar todos os testes costumam causar regressões em comportamentos que já estavam estáveis. Toda alteração, por menor que seja, deve ser tratada como uma nova iteração e testada. O segundo risco é o desvio nos critérios de avaliação. Com o tempo, as equipes podem, sem perceber, baixar o padrão do que consideram um teste aprovado, especialmente sob pressão para lançar. Os critérios definidos no início devem continuar sendo a referência. Se parecerem rígidos demais, o certo é revisá-los de forma deliberada, não deixar o padrão cair aos poucos.

Escalando com confiança

Aumentar o tráfego é uma decisão baseada em confiança, não em tempo. O sinal para expandir é quando o agente atinge os critérios de avaliação de forma consistente em vários testes, as métricas da plataforma estão estáveis e os lançamentos em etapas não mostram regressão relevante em relação ao grupo de controle.

Uma dúvida comum nessa fase é: quanto tráfego é suficiente para tirar conclusões? Lotes com menos de 100 chamadas por etapa têm variação demais para avaliar resultados com confiança. Uma taxa de aprovação de 60% em 25 chamadas e a mesma taxa em 100 chamadas representam níveis de confiança bem diferentes. Além do número, o lote precisa ser grande o bastante para trazer toda a variedade de entradas reais, incluindo exceções, intenções incomuns e falhas que só aparecem em volume e raramente em amostras pequenas.

Mais tráfego amplifica tanto o que está funcionando quanto o que não está. Expandir antes de resolver os principais padrões de falha cria uma demanda de suporte difícil de reverter.

Iterar e repetir

Saber quando parar é tão importante quanto saber o que corrigir. A iteração tem retorno decrescente, e o sinal para pausar é quando o agente está atendendo consistentemente aos critérios definidos no início. A partir daí, mudanças trazem mais risco do que benefício.

O que significa "atender consistentemente aos critérios" varia conforme o contexto. Equipes com acesso limitado a dados ou integrações incompletas podem considerar taxas de escalada em torno de 50% como teto realista até resolver essas restrições. Onde o acesso a dados é bom, as melhores implantações costumam buscar conclusão de tarefas acima de 80% e escalada abaixo de 20%. Mais importante do que qualquer número é a estabilidade: desempenho consistente por várias semanas de tráfego real, sem regressão relevante nos testes, é o verdadeiro sinal. Quando o ganho marginal da próxima iteração é menor que o risco de regressão, é hora de parar.

Isso não significa que o trabalho acabou. Quando surgirem novos requisitos, o processo recomeça do início. As perguntas de escopo da primeira versão continuam valendo para a segunda. A diferença é que, na segunda rodada, a equipe já tem um conjunto de testes, uma base de avaliação e experiência operacional que antes precisou construir do zero. Essa vantagem acumulada é o que separa organizações que extraem valor duradouro de agentes de voz daquelas que ficam presas em provas de conceito.

Conclusão

As equipes que vimos fechar a lacuna entre desvio e resolução são aquelas que definem o que é bom antes de começar a construir, mantêm disciplina durante as iterações e tratam cada implantação como base para a próxima. Agentes conversacionais não são uma solução única – conversas reais sempre trazem exceções que nenhum teste prevê totalmente, e o trabalho de melhoria não termina no lançamento.

O ElevenAgents foi criado pensando nessa realidade. Testes de Agente, Análise de Conversas e lançamentos em etapas são a base para transformar uma prova de conceito em um sistema que realmente resolve problemas dos clientes em escala – e não só os desvia. Essa é a diferença que vale a pena buscar.

O ElevenAgents foi criado com essa realidade em mente. Testes de Agente, Análise de Conversa e lançamentos graduais são a base para transformar uma prova de conceito em um sistema que realmente resolve problemas dos clientes em escala — não só desvia. Essa é a diferença que vale a pena buscar.