AWS dá a agentes de código uma prévia ao vivo do site direto da sessão isolada

A Amazon Web Services adicionou ao AgentCore runtime a função Session endpoints. O AgentCore runtime executa cada sessão de um agente de IA em uma microVM isolada própria. Até agora, tudo o que o agente subia lá dentro, como um site, não era visível do lado de fora. Agora a sessão tem uma URL protegida: você a abre no navegador e acompanha o agente de código montando o aplicativo web. Cada alteração aparece na página em segundos, antes mesmo de alguém publicar qualquer coisa em uma hospedagem.

Por que ver o site enquanto o agente escreve o código

Agentes de código já constroem dashboards funcionais, páginas de produto e protótipos. A forma mais simples de revisar esse trabalho é na mão: abrir o aplicativo, clicar, pedir uma mudança, ver o resultado. O ciclo é rápido enquanto o aplicativo roda no mesmo lugar em que o agente edita os arquivos. Se for preciso primeiro copiá-lo e fazer o deploy em outro ambiente, cada alteração espera o deploy, e a revisão passa a andar na velocidade dele.

Os Session endpoints eliminam essa etapa. Eles não substituem a hospedagem de produção: a AWS recomenda explicitamente entregar o aplicativo aos usuários por um serviço como o AWS Amplify Hosting. O endpoint serve para construir, testar e aprovar o que o agente fez.

Como funciona o ambiente de demonstração

O exemplo do repositório agentcore-samples tem quatro partes:

• O agente de código roda na sessão, na porta 8080, e edita os arquivos do site com quatro ferramentas: list, read, write e edit.
• O servidor de desenvolvimento Vite escuta a porta 8090, serve o site e avisa o navegador via WebSocket a cada arquivo salvo.
• Na sua máquina, o aplicativo PreviewApp exibe a página: chat à esquerda, site ao vivo à direita. Ele envia seus pedidos ao InvokeAgentRuntime e abre um ponto de entrada local para o site.
• Para tomar decisões, o agente chama o modelo Claude Haiku 5.5 no Amazon Bedrock.

A primeira chamada ao InvokeAgentRuntime inicia a sessão, e o endereço do Session endpoint chega no cabeçalho da resposta. O resto é simples. Você pede para trocar o site para um tema escuro de café. O agente lê src/main.js, src/style.css e index.html, salva os estilos, e o site muda sem recarregar a página. Os passos do agente chegam ao chat em streaming, como server-sent events. O pedido seguinte, deixar o botão "Order ahead" verde, segue o mesmo caminho: o agente altera apenas o style.css.

Seis detalhes para conhecer na configuração

• Você escolhe as portas. No parâmetro allowedPorts, ao criar o runtime, informam-se de 1 a 5 portas ou intervalos dentro de 8000–12000, excluindo as portas reservadas da plataforma. Liberar uma porta não inicia nenhum servidor: o aplicativo precisa escutar nela em 0.0.0.0.
• A URL chega junto com a sessão, no cabeçalho X-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Url.
• Toda requisição é autenticada. Para um runtime com IAM, são necessários a assinatura SigV4 e a permissão bedrock-agentcore:InvokeAgentRuntimeProxy; para um runtime com autorizador JWT, é preciso um token bearer. Conhecer o endereço não basta.
• A porta é escolhida por um prefixo no nome do host, por exemplo 8090--<id>.runtime.bedrock-agentcore.<region>.on.aws. O cliente sempre se conecta à 443.
• Passam HTTP/1.1, HTTP/2, server-sent events, gRPC e WebSocket.
• O endpoint é vinculado a uma única sessão e deixa de existir junto com ela.

O navegador não sabe assinar com SigV4 as requisições da página. Por isso, o SDK bedrock-agentcore abre na sua máquina um ponto local em localhost:8088, que adiciona as credenciais a cada requisição e ao handshake do WebSocket. Ele escuta apenas 127.0.0.1 e rejeita conexões WebSocket vindas de páginas de outras origens.

Separadamente, a porta 8081 fica ativa na sessão: nela o agente expõe a rota /status, com a lista de requisições e de arquivos alterados. Pelo mesmo endpoint, muda apenas o número da porta. A porta 8080 não está na lista de propósito: o InvokeAgentRuntime chega ao agente mesmo sem o Session endpoint.

O que o endpoint rejeita e o que levar em conta

As recusas do runtime chegam com um status HTTP, corpo vazio e o código de erro no cabeçalho, o que facilita distingui-las de erros do seu aplicativo:

• porta fora de allowedPorts: 403 AccessDenied;
• requisição sem credenciais válidas: 403 AccessDenied ou 401 AuthenticationRequired;
• porta permitida em que ninguém está escutando: 502 PortNotReachable;
• URL de uma sessão já encerrada: 404 SessionNotFound.

Todas as requisições vão para o AWS CloudTrail como eventos InvokeAgentRuntimeProxy. O runtime remove os cabeçalhos de autenticação antes de encaminhar a requisição, então o site não vê a assinatura.

Há limitações. O recurso funciona apenas com runtimes microVM, não com o tipo de computação Instances. A URL é acessível por HTTPS público, e o AWS PrivateLink não é compatível com conexões de entrada.

Se o runtime trocar o nó de computação da sessão, as conexões serão encerradas, e as alterações do agente podem se perder se não houver armazenamento persistente. O site e o agente vivem na mesma sessão e não são separados por permissões, por isso convém dar à função de execução apenas as permissões necessárias. As ferramentas de arquivo do agente não saem da pasta do site.

Se terceiros puderem enviar prompts, a AWS recomenda o Amazon Bedrock Guardrails e uma revisão manual das alterações antes da publicação.

O exemplo é implantado sem Docker: o agente vai para o Amazon S3 em um arquivo zip, por direct code deployment para Node.js 22. São necessários Python 3.10+, bedrock-agentcore 1.25.2+ e boto3 1.43.122+. Depois dos experimentos, execute o cleanup.py, que remove o runtime, o código e a função IAM.

Para equipes que constroem agentes de desenvolvimento, é uma forma prática de encurtar o ciclo "pedir, olhar, ajustar". Só não deixe o preview ligado por mais tempo do que o necessário: o ponto local funciona com as suas credenciais.