AWS añade endpoints de sesión al runtime de Bedrock AgentCore para vistas previas de apps en vivo
AWS presentó los endpoints de sesión en el runtime de Amazon Bedrock AgentCore, que permiten a los desarrolladores previsualizar aplicaciones web en el navegador mientras un agente de codificación las construye.
Respuesta rápida
¿Qué anunció AWS para previsualizar el trabajo de un agente de codificación en Amazon Bedrock AgentCore?
AWS indicó que el runtime de Amazon Bedrock AgentCore ahora admite los endpoints de sesión, URL autenticadas que permiten a los desarrolladores abrir directamente en su navegador una aplicación web que un agente de codificación está construyendo dentro de una sesión aislada. Los endpoints redirigen el tráfico HTTP y WebSocket a los puertos que el desarrollador autorice, de modo que los cambios se reflejan sin necesidad de un paso de implementación independiente.
Claves
- AWS presentó los endpoints de sesión, una función del runtime de Amazon Bedrock AgentCore que permite a los desarrolladores abrir directamente en su navegador una aplicación web que se ejecuta dentro de la sesión de un agente.
- Cada sesión de agente se ejecuta en su propia microVM aislada, y los desarrolladores eligen a qué puertos puede acceder un endpoint de sesión, entre una y cinco entradas dentro del rango 8000-12000, configurando el parámetro allowedPorts al invocar CreateAgentRuntime.
- AWS indicó que cada solicitud a través de un endpoint de sesión está autenticada, mediante firmas SigV4 para los runtimes que dependen de IAM o tokens portadores para los runtimes con un autorizador JWT.
- AWS publicó un ejemplo en el repositorio de GitHub agentcore-samples que muestra un agente de codificación que mantiene en ejecución, dentro de su sesión, un sitio web creado con Vite, de modo que los cambios aparecen en el navegador a medida que el agente edita los archivos.
- AWS señaló que un endpoint de sesión está limitado a una sola sesión y está pensado para construir, probar y revisar el trabajo del agente, no para ofrecer aplicaciones a usuarios finales, lo cual requiere implementarlas en un servicio de alojamiento independiente como AWS Amplify Hosting.
Qué anunció AWS
Amazon Web Services informó que el runtime de Amazon Bedrock AgentCore ahora admite una función llamada endpoints de sesión, que permite a los desarrolladores abrir e interactuar, directamente en su propio navegador, con una aplicación web que un agente de codificación está construyendo, mientras el agente sigue trabajando en ella.
Según AWS, el runtime de AgentCore ya ejecuta cada sesión de agente en su propia microVM aislada. Los endpoints de sesión añaden una URL autenticada para esa sesión que redirige el método HTTP, la ruta, la cadena de consulta y el cuerpo de cada solicitud, así como las conexiones WebSocket, a los puertos que el desarrollador haya autorizado. AWS señaló que esto permite al desarrollador observar cómo se actualiza una página a medida que el agente guarda cada archivo, en lugar de esperar a que la aplicación se copie y se implemente en otro lugar antes de cada revisión.
Cómo funcionan los endpoints de sesión
AWS describió seis detalles que rigen el funcionamiento de los endpoints de sesión:
- Selección de puertos: los desarrolladores configuran un parámetro
allowedPortsal invocarCreateAgentRuntime, especificando entre una y cinco entradas, cada una un puerto único o un rango dentro de 8000-12000, excluyendo los puertos reservados de la plataforma. AWS señaló que autorizar un puerto no inicia un servidor; la aplicación debe escucharlo, vinculada a0.0.0.0. - Entrega de la URL: la respuesta de
InvokeAgentRuntimeincluye la URL del endpoint en el encabezadoX-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url, que los SDK compatibles exponen comosessionEndpointUrl. - Autenticación: para los runtimes que usan AWS IAM, AWS indicó que cada solicitud HTTP, cada flujo HTTP/2 y cada negociación WebSocket lleva una firma de la Versión 4 de Firma, y el solicitante necesita el permiso
bedrock-agentcore:InvokeAgentRuntimeProxy. Para los runtimes con un autorizador JWT, cada solicitud lleva en su lugar un token portador. - Enrutamiento de puertos mediante el nombre de host: AWS explicó que el cliente siempre se conecta por el puerto 443, y un prefijo en el nombre de host selecciona el puerto de destino dentro de la sesión.
- Soporte de protocolos: AWS indicó que los endpoints transportan tráfico HTTP/1.1, HTTP/2 (incluidos eventos enviados por el servidor y gRPC) y WebSocket.
- Alcance de la sesión: AWS señaló que la URL requiere credenciales en cada solicitud y solo dura mientras dure la sesión, y está pensada para construir, probar y revisar el trabajo del agente. Para ofrecer una aplicación a los usuarios finales, AWS recomendó implementarla en un servicio de alojamiento como AWS Amplify Hosting.
AWS también señaló que, dado que un navegador no puede adjuntar por sí solo una firma SigV4 ni un token portador, el cliente de endpoints de sesión del SDK bedrock-agentcore puede abrir un endpoint local en la máquina del desarrollador, que añade las credenciales a cada solicitud y negociación WebSocket antes de reenviarla al navegador.
AWS distinguió el endpoint de sesión del endpoint de runtime que el runtime de AgentCore ya ofrece. Un endpoint de runtime, como DEFAULT, controla a qué versión de un agente acceden los solicitantes y permite a los desarrolladores mantener versiones separadas para desarrollo y producción. Un endpoint de sesión, en cambio, refleja la versión del agente que se ejecuta en esa sesión específica y deja de funcionar cuando la sesión finaliza.
El recorrido del ejemplo
AWS publicó un ejemplo con cuatro partes: un agente de codificación que se ejecuta en el puerto 8080 y edita los archivos de un sitio web mediante herramientas de listado, lectura, escritura y edición; un servidor de desarrollo Vite en el puerto 8090 iniciado por el agente, que sirve el sitio web y envía los cambios guardados al navegador a través de su WebSocket de recarga en caliente; una aplicación local PreviewApp que sirve una página de vista previa, envía instrucciones a InvokeAgentRuntime y abre un endpoint local para el sitio web; y la propia página de vista previa, que carga el sitio web a través de los endpoints local y de sesión mientras envía instrucciones al agente. El ejemplo completo, incluido el notebook que sigue la publicación, se encuentra en la carpeta 14-remote-access del repositorio de GitHub agentcore-samples.
Fuente: AWS Machine Learning Blog, "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime", publicado el 30 de octubre de 2026.
Preguntas frecuentes
- ¿Qué es un endpoint de sesión en el runtime de Amazon Bedrock AgentCore?
- AWS lo describe como una URL autenticada vinculada a una única sesión de agente que redirige las solicitudes HTTP y las conexiones WebSocket a los puertos que el desarrollador autorice, permitiéndole abrir en su propio navegador una aplicación que el agente está construyendo.
- ¿Cómo protege AWS el tráfico de los endpoints de sesión?
- AWS indicó que cada solicitud está autenticada: los runtimes que usan IAM requieren una firma SigV4 además del permiso bedrock-agentcore:InvokeAgentRuntimeProxy, mientras que los runtimes con un autorizador JWT requieren un token portador en cada solicitud.
- ¿Puede usarse un endpoint de sesión para ofrecer una aplicación a los usuarios finales?
- No. AWS señaló que la URL del endpoint de sesión solo dura mientras dure la sesión y está pensada para construir, probar y revisar el trabajo del agente; ofrecer una aplicación a los usuarios requiere implementarla en un servicio de alojamiento independiente como AWS Amplify Hosting.
- ¿Dónde pueden encontrar los desarrolladores código de ejemplo para esta función?
- AWS remitió a la carpeta 14-remote-access del repositorio de GitHub agentcore-samples, que incluye un notebook que muestra un agente de codificación que mantiene en ejecución un sitio web Vite dentro de su sesión para la vista previa en vivo.