AWS explicó cómo desplegar agentes de voz AI de Pipecat en Bedrock AgentCore Runtime

AWS ha lanzado la primera parte de una guía práctica sobre cómo desplegar agentes de voz Pipecat en Amazon Bedrock AgentCore Runtime. El enfoque no está en los modelos en sí, sino en la capa de transporte, que determina si la conversación sonará natural o si el usuario experimentará pausas y retrasos.

Por qué la latencia es importante

Un agente de voz casi siempre opera en condiciones desafiantes: navegador, aplicación móvil o llamada telefónica, red inestable, picos de carga y expectativa de respuesta en tiempo real. AWS enfatiza que para un diálogo natural, la latencia debe permanecer casi imperceptible — típicamente dentro de un segundo desde el final de la declaración del usuario hasta el inicio de la respuesta del agente. Si no, la conversación se rompe: el interlocutor interrumpe al agente, piensa que se ha congelado o simplemente se va. Esto es especialmente crítico para soporte, asistentes virtuales y campañas de salida.

Para mitigar este riesgo, AWS sugiere ejecutar agentes Pipecat en Bedrock AgentCore Runtime — un entorno serverless seguro para agentes de IA. Cada sesión se ejecuta en una microVM aislada, la plataforma se escala automáticamente para picos de tráfico y puede mantener conversaciones continuas hasta ocho horas. Esto importa para llamadas largas y de múltiples pasos donde no puede simplemente cortar el contexto. Otra ventaja es pagar solo por los recursos realmente consumidos, sin necesidad de mantener reservas de servidor para carga máxima.

Pipecat en sí puede empaquetarse en un contenedor e implementarse con overhead mínimo si la imagen se compila para ARM64.

Qué opciones existen

En la primera parte, AWS revisa el camino desde el cliente hasta el agente — ese "primer salto" que más fuertemente afecta la percepción de velocidad. La empresa compara cuatro enfoques: WebSockets regulares, WebRTC con relé TURN, WebRTC gestionado a través de proveedores especializados y telefonía para trabajar con PSTN y centros de contacto. Cada opción tiene su propio equilibrio entre simplicidad, confiabilidad y calidad de conexión.

La idea es simple: no existe un único transporte mejor para todos los escenarios, pero hay casos de uso claros donde cada uno parece un punto de partida razonable.

• WebSockets — la opción más simple para prototipos y escenarios ligeros en web y aplicaciones móviles.
• WebRTC con TURN — la mejor opción si necesita menor latencia y resiliencia en redes deficientes.
• WebRTC gestionado — el camino a producción cuando quiere descargar la red de medios global, análisis e infraestructura de relé a un servicio externo.
• Telefonía — una opción para llamadas, reemplazo de IVR, campañas de salida e integración con centros de contacto.

Para WebSockets, AWS muestra un enfoque maximalmente directo. El cliente primero solicita una dirección firmada desde un servidor intermedio; este servidor genera una URL pre-firmada con firma SigV4 a través de AWS SDK; luego el navegador se conecta directamente al agente en la dirección /ws. Esto mantiene las credenciales fuera del lado del cliente y el tráfico en sí después de establecida la conexión fluye sin un intermediario innecesario. AWS llama a esto un buen punto de partida: es más simple que las alternativas, soportado nativamente por la mayoría de clientes y adecuado para validar rápidamente un producto.

Qué considerar en producción

Si el objetivo no es una demostración sino una interfaz conversacional estable, AWS recomienda mirar hacia WebRTC. Este transporte típicamente funciona sobre UDP, maneja mejor las condiciones de red fluctuantes y entrega audio más rápido en ambas direcciones. Pero AgentCore tiene matices arquitectónicos.

Una conexión peer-to-peer directa no funciona aquí porque el entorno de runtime no recibe una IP pública. El escenario STUN tampoco funciona como la ruta principal: AWS señala que NAT Gateway usa NAT simétrico, lo que rompe la perforación directa de conexión. Por lo tanto la recomendación práctica es relé TURN y configuración de VPC para el runtime.

En el esquema de funcionamiento, necesita configurar la variable ICE_SERVER_URLS tanto en el servidor intermedio como en el entorno del agente, luego colocar AgentCore Runtime en una subred privada de VPC y darle acceso de salida a través de NAT Gateway.

Como la opción nativa de AWS para TURN, la empresa ofrece Amazon Kinesis Video Streams: el servicio proporciona credenciales ICE temporales y rotadas automáticamente a través de la API GetIceServerConfig. Esto elimina dependencias externas, pero hay limitaciones: un canal de señalización activo cuesta $0,03 por mes, el límite es 5 TPS por canal, lo que significa a volúmenes altos de nuevas sesiones necesitará distribuir carga en múltiples canales. Además aún necesita acceso a internet para llegar a KVS.

AWS también menciona por separado proveedores de WebRTC gestionados de AWS Marketplace. Esta opción es útil si además del transporte necesita nodos SFU/TURN distribuidos globalmente, observabilidad integrada y soporte para salas multiusuario, no solo diálogo uno a uno.

Para escenarios de telefonía la lógica es similar: el agente continúa manteniendo un flujo de audio bidireccional constante pero se conecta al proveedor de telecom a través de SIP, WebSocket o WebRTC. Pipecat ya proporciona transportes y serializadores listos, así que la tarea se reduce no a construir una pila de voz desde cero sino a elegir el canal correcto.

Qué significa esto

AWS efectivamente muestra que el cuello de botella en agentes de IA de voz hace mucho se ha desplazado del modelo a la infraestructura para entrega de audio. Para equipos esta es una guía útil: puede comenzar con WebSockets, pero para producción seria casi inevitablemente necesitará elegir entre WebRTC, redes de medios gestionadas y telefonía — dependiendo de dónde exactamente el usuario está hablando con el agente.