AWS explicou como implantar agentes de voz AI do Pipecat no Bedrock AgentCore Runtime

A AWS lançou a primeira parte de um guia prático sobre como implantar agentes de voz Pipecat no Amazon Bedrock AgentCore Runtime. O foco não está nos modelos em si, mas na camada de transporte, que determina se a conversa soará natural ou se o usuário experimentará pausas e atrasos.

Por que a latência é importante

Um agente de voz quase sempre opera em condições desafiadoras: navegador, aplicativo móvel ou chamada telefônica, rede instável, picos de carga e expectativa de resposta em tempo real. A AWS enfatiza que para um diálogo natural, a latência deve permanecer quase imperceptível — tipicamente dentro de um segundo do final da declaração do usuário até o início da resposta do agente. Caso contrário, a conversa se quebra: o interlocutor interrompe o agente, pensa que ele travou ou simplesmente vai embora. Isto é especialmente crítico para suporte, assistentes virtuais e campanhas de saída.

Para mitigar esse risco, a AWS sugere executar agentes Pipecat no Bedrock AgentCore Runtime — um ambiente serverless seguro para agentes de IA. Cada sessão é executada em uma microVM isolada, a plataforma dimensiona automaticamente para picos de tráfego e pode manter conversas contínuas por até oito horas. Isso é importante para chamadas longas e multi-etapas onde você não pode simplesmente cortar o contexto. Outra vantagem é pagar apenas pelos recursos realmente consumidos, sem necessidade de manter reservas de servidor para carga de pico.

O Pipecat em si pode ser empacotado em um contêiner e implantado com overhead mínimo se a imagem for compilada para ARM64.

Quais opções existem

Na primeira parte, a AWS revisa o caminho do cliente para o agente — aquele "primeiro salto" que mais fortemente afeta a percepção de velocidade. A empresa compara quatro abordagens: WebSockets regulares, WebRTC com retransmissão TURN, WebRTC gerenciado através de provedores especializados e telefonia para trabalhar com PSTN e centros de contato. Cada opção tem seu próprio equilíbrio entre simplicidade, confiabilidade e qualidade de conexão.

A ideia é simples: não existe um único melhor transporte para todos os cenários, mas existem casos de uso claros onde cada um parece um ponto de partida razoável.

• WebSockets — a opção mais simples para protótipos e cenários leves em web e aplicativos móveis.
• WebRTC com TURN — a melhor escolha se você precisar de latência mais baixa e resiliência em redes pobres.
• WebRTC gerenciado — o caminho para a produção quando você quer descarregar a rede de mídia global, análise e infraestrutura de retransmissão para um serviço externo.
• Telefonia — uma opção para chamadas, substituição de IVR, campanhas de saída e integração com centros de contato.

Para WebSockets, a AWS mostra uma abordagem maximalmente direta. O cliente primeiro solicita um endereço assinado de um servidor intermediário; este servidor gera uma URL pré-assinada com assinatura SigV4 via AWS SDK; então o navegador se conecta diretamente ao agente no endereço /ws. Isso mantém as credenciais fora do lado do cliente e o tráfego em si após a conexão ser estabelecida flui sem um intermediário desnecessário. A AWS chama isso de um bom ponto de partida: é mais simples que as alternativas, nativamente suportado pela maioria dos clientes e adequado para validar rapidamente um produto.

O que considerar em produção

Se o objetivo não é um demo mas uma interface conversacional estável, a AWS recomenda olhar para WebRTC. Este transporte tipicamente funciona sobre UDP, lida melhor com condições de rede flutuantes e entrega áudio mais rapidamente em ambas as direções. Mas AgentCore tem nuances arquiteturais.

Uma conexão peer-to-peer direta não funciona aqui porque o ambiente de runtime não recebe um IP público. O cenário STUN também não funciona como o caminho principal: a AWS observa que o NAT Gateway usa NAT simétrico, o que quebra o buraco direto de conexão. Portanto, a recomendação prática é retransmissão TURN e configuração de VPC para o runtime.

No esquema funcionando, você precisa configurar a variável ICE_SERVER_URLS tanto no servidor intermediário quanto no ambiente do agente, então colocar AgentCore Runtime em uma subnet privada de VPC e dar a ele acesso de saída via NAT Gateway.

Como a opção nativa da AWS para TURN, a empresa oferece Amazon Kinesis Video Streams: o serviço fornece credenciais ICE temporárias e rotacionadas automaticamente através da API GetIceServerConfig. Isso elimina dependências externas, mas há limitações: um canal de sinalização ativo custa $0,03 por mês, o limite é 5 TPS por canal, o que significa em volumes altos de novas sessões você precisará distribuir carga em múltiplos canais. Além disso você ainda precisa de acesso à internet para alcançar KVS.

A AWS também menciona separadamente provedores gerenciados de WebRTC do AWS Marketplace. Esta opção é útil se além do transporte você precisa de nós SFU/TURN distribuídos globalmente, observabilidade integrada e suporte para salas multi-usuário, não apenas diálogo um-a-um.

Para cenários de telefonia a lógica é similar: o agente continua mantendo um fluxo de áudio bidirecional constante mas se conecta ao provedor de telecom via SIP, WebSocket ou WebRTC. Pipecat já fornece transportes e serializadores prontos, então a tarefa se reduz não a construir uma pilha de voz do zero mas a escolher o canal certo.

O que isso significa

A AWS efetivamente mostra que o gargalo em agentes de IA de voz há muito tempo mudou do modelo para a infraestrutura de entrega de áudio. Para equipes isto é uma diretriz útil: você pode começar com WebSockets, mas para produção séria você quase inevitavelmente precisará escolher entre WebRTC, redes de mídia gerenciadas e telefonia — dependendo de onde exatamente o usuário está falando com o agente.