Em 30 de outubro de 2026, a AWS publicou no blog de machine learning um tutorial que mostra como acompanhar, no navegador, um site sendo modificado por um agente de programação enquanto ele trabalha. A peça se apoia no Amazon Bedrock AgentCore runtime, que executa cada sessão de agente em uma microVM isolada, e nos Session endpoints, recurso que entrega a cada sessão uma URL autenticada capaz de encaminhar requisições HTTP e conexões WebSocket para as portas liberadas pelo desenvolvedor.
A proposta é encurtar o ciclo de revisão. Em vez de copiar o aplicativo para outro ambiente e esperar uma implantação a cada alteração, o agente edita os arquivos no mesmo lugar em que o servidor está rodando.
O exemplo descrito no material mantém um site feito com Vite ativo dentro da sessão e abre uma página local com um chat à esquerda e o site ao vivo à direita. O pedido de teste é trocar o tema para escuro; conforme o agente grava cada arquivo, a página muda na tela sem recarregar.
Como o endpoint de sessão funciona
O endereço não é fixo nem público. Ele chega junto com a chamada de invocação do agente: a resposta da operação InvokeAgentRuntime traz a URL no cabeçalho X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url, exposto por SDKs compatíveis como sessionEndpointUrl.
A porta interna é escolhida por um prefixo no nome do host, enquanto o cliente sempre conecta na porta 443. Assim, um endereço começando com 8090-- aponta para a porta 8090 dentro da sessão, e outro com 8081-- chega ao serviço que escuta em 8081.
A configuração de portas é feita no momento da criação do runtime, pela chamada CreateAgentRuntime. O campo allowedPorts aceita de uma a cinco entradas, cada uma com uma porta única ou uma faixa dentro do intervalo de 8000 a 12000, excluindo as portas reservadas da plataforma.
Liberar uma porta não inicia nenhum servidor: a aplicação precisa estar de fato escutando nela, vinculada a 0.0.0.0. O túnel transporta HTTP/1.1, HTTP/2 — incluindo server-sent events e gRPC, e WebSocket, o que cobre boa parte dos fluxos interativos de desenvolvimento web.
Autenticação e limites de uso
Cada requisição é autenticada. Em runtimes que usam AWS Identity and Access Management (IAM), toda chamada HTTP, fluxo HTTP/2 e handshake WebSocket carrega uma assinatura Signature Version 4 (SigV4).
O chamador também precisa da permissão bedrock-agentcore:InvokeAgentRuntimeProxy sobre o runtime e sobre o endpoint correspondente. Para runtimes com autorizador de JWT de entrada, o pedido leva um token bearer.
Conhecer a URL, portanto, não basta para acessar a aplicação.
O escopo é uma única sessão. O endereço exige credenciais em cada requisição e dura apenas enquanto a sessão existir, o que o posiciona como ferramenta de construção, teste e revisão, não como hospedagem de produção.
Para servir um app aos usuários finais, o próprio material indica um serviço de hospedagem como o AWS Amplify Hosting. Como um navegador não consegue assinar requisições com SigV4 nem anexar um token bearer por conta própria, o SDK bedrock-agentcore oferece um cliente que abre um endpoint local na máquina do desenvolvedor, no exemplo, em http://localhost:8088, e acrescenta as credenciais antes de repassar o tráfego.
O navegador fala com esse endereço local, e não diretamente com a sessão remota.
O que o teste com vite demonstra
O walkthrough vai além da página principal. Ele também observa o comportamento de uma segunda porta na mesma sessão e o que acontece quando o Session endpoint recusa requisições, o que ajuda a entender os limites do recurso.
O código completo, incluindo o notebook seguido no artigo, está na pasta 14-remote-access do repositório agentcore-samples no GitHub.
Por que isso importa
Agentes de programação já produzem dashboards, páginas de produto e protótipos que equipes querem experimentar. Quando a revisão depende de uma implantação a cada mudança, o ritmo do trabalho cai para o da esteira de deploy.
Manter o app vivo ao lado do agente, com uma URL autenticada e temporária, encurta esse laço e permite que pessoas não técnicas validem o resultado em segundos. Ao mesmo tempo, a separação entre prévia de sessão e hospedagem definitiva deixa claro que o recurso foi desenhado para iterar com segurança, não para substituir a infraestrutura de produção.
Fontes e links
- AWS
- Pasta 14-remote-access no repositório agentcore-samples
- Repositório agentcore-samples
- Documentação de Session endpoints do AgentCore
