AWS Bedrock AgentCore Runtime: terminal stateful e loop de avaliação
TL;DR
O Amazon Bedrock AgentCore Runtime ganhou Interactive Shells, um terminal persistente com estado e reconexão por sessão, o que reduz o atrito entre investigação manual, depuração e automação de tarefas dentro do contexto do agente. Em paralelo, o stack de performance/evaluation fecha o ciclo com traces, avaliações, recomendações, batch evaluations e A/B tests para validar mudanças antes de promover em tráfego real.
O que mudou no AgentCore Runtime
A novidade mais prática é a chegada de um terminal interativo dentro da sessão do runtime, acessado por InvokeAgentRuntimeCommandShell. A sessão mantém estado de diretório, variáveis de ambiente e histórico, e a reconexão pode retomar o mesmo shell com session_id e shellId sobre WebSocket, em vez de exigir uma nova execução do zero. A documentação oficial da AWS descreve também uma segunda superfície complementar: execução one-shot de comandos com streaming e exit code via InvokeAgentRuntimeCommand, útil para tarefas determinísticas e paralelizáveis (Interactive Shells; Execute shell commands).
Na prática, isso aproxima o runtime de uma experiência de terminal real, mas dentro da infraestrutura do agente. Você consegue inspecionar arquivos, testar dependências, ajustar um ambiente e voltar depois sem perder contexto. Para times que já usam agentes em etapas longas de raciocínio, essa persistência reduz o custo de recomeçar toda vez que um passo falha.
Interactive Shells vs. execução one-shot
Vale separar as duas formas de executar shell no AgentCore. O terminal interativo é stateful: ele preserva contexto entre interações e foi desenhado para uma conversa contínua com o ambiente. Já a execução de comando one-shot é mais parecida com um job curto, com saída em tempo real e término explícito, o que combina com verificações, scripts e automações que não precisam de intervenção humana contínua (Shell execution).
Esta seção descreve a versão do runtime documentada em junho de 2026. APIs de IA e orquestração mudam rápido — confira o changelog oficial antes de levar o fluxo para produção.
O detalhe operacional que faz diferença
O protocolo do terminal usa WebSocket com streaming bidirecional, então entrada e saída chegam em tempo real. A AWS também documenta um limite operacional de até 10 sessões de shell ativas por runtime, o que é um dado importante para quem pretende usar o recurso em ambientes compartilhados ou em pipelines de teste concorrentes (Interactive Shells).
Esse tipo de restrição muda o desenho de tooling. Em vez de tratar o shell como um console livre para todos, faz sentido pensar em filas, isolamento por sessão e limpeza explícita de recursos. Em equipes de plataforma, isso se conecta diretamente com observabilidade e controle de custo.
Como o loop de performance e avaliação fecha o ciclo
O segundo bloco importante do anúncio é o loop de performance: o AgentCore foi desenhado para transformar traces em avaliações, sugerir melhorias com recommendations e validar mudanças em escala com batch evaluations e A/B tests. A proposta é sair de um fluxo puramente artesanal — onde alguém lê logs e tira conclusões — para um ciclo mais sistemático de observação, julgamento e validação (Agent quality optimization; capabilities for optimizing agent performance).
O ponto central aqui é não confiar apenas em impressão subjetiva. O runtime gera rastros, os evaluations atribuem notas com avaliadores built-in ou custom, e o sistema permite comparar mudanças antes de promover uma variante. Isso é útil quando o problema não é “o agente funciona?”, mas “ele funciona de forma consistente no fluxo real que a empresa precisa?”.
Traces virando avaliações
O serviço de AgentCore Evaluations consolida traces e aplica avaliadores com abordagem de LLM-as-a-judge. A documentação também menciona avaliadores built-in e custom, cada um com ARN e políticas de acesso, o que facilita governança em times maiores (AgentCore Evaluations).
Isso importa porque agente bom não é só o que responde certo em uma demo. Em produção, ele precisa repetir comportamento aceitável em cenários variados, com prompts imperfeitos, entradas ambíguas e chamadas externas que mudam de latência. Uma avaliação padronizada ajuda a detectar regressões antes que o problema vire incidente.
Batch evaluations para escala
O modo batch roda avaliadores sobre múltiplas sessões com orquestração server-side e pode descobrir sessões a partir de CloudWatch Logs. Isso reduz o trabalho manual de montar amostras e permite avaliar um volume maior de interações do agente com menos operação humana (Batch evaluation).
Esse desenho conversa bem com times que já têm observabilidade em cloud. Em vez de exportar dados para planilhas, a equipe mantém o ciclo dentro do ecossistema da AWS, o que facilita repetir o processo a cada mudança de prompt, ferramenta ou política de execução.
A/B tests para validar no tráfego
O A/B testing do AgentCore divide tráfego entre variantes e acompanha métricas até atingir significância estatística antes de promover mudanças. É uma etapa importante porque nem toda melhoria que parece boa em avaliação offline vai se manter em uso real (A/B testing).
Na prática, isso permite comparar duas versões de um agente, um prompt ou uma configuração de runtime com menos achismo. Em sistemas com usuários reais, o valor está em medir impacto contínuo e não apenas em observar casos de laboratório.
Uma leitura prática do fluxo de trabalho
Se você estiver estruturando um pipeline com AgentCore, um desenho razoável é: usar o terminal interativo para investigação e ajuste; usar execução one-shot para tarefas curtas e automáticas; coletar traces; rodar avaliações; e fechar com batch ou A/B quando a mudança afetar comportamento de produção. Esse encadeamento separa bem o que é exploração humana do que é validação mecanizada.
O ganho também é de governança. Quando o shell guarda estado, a depuração fica menos frágil. Quando a avaliação vira processo formal, o time consegue responder por que uma alteração entrou, qual evidência a sustenta e qual métrica será usada para aprovar a próxima mudança.
Por que isso importa pro dev brasileiro
No Brasil, esse tipo de fluxo pesa ainda mais porque muitos times trabalham com orçamento em BRL apertado, prazos curtos e infraestrutura concentrada em regiões como us-east-1 por custo e disponibilidade. Isso aumenta a sensibilidade a latência, reconexões e ciclos longos de experimentação. Um terminal stateful reduz retrabalho; um loop de avaliação ajuda a gastar menos tempo com validação manual e mais com ajuste de comportamento.
Há também um impacto direto em conformidade e risco. Em casos que envolvem dados pessoais, a LGPD força mais cuidado com observabilidade, retenção e acesso aos traços. Ter avaliações automatizadas e uma rota clara para testar mudanças antes de ampliar tráfego ajuda a reduzir exposição operacional sem depender de revisão ad hoc de cada interação.
Como começar sem complicar
Se a sua equipe já usa AWS, o caminho mais rápido é ler em sequência a documentação do terminal interativo, da execução de comandos e das avaliações. Depois disso, vale montar um fluxo pequeno: uma sessão com shell persistente para depuração, uma chamada one-shot para automatizar um comando, e uma avaliação batch sobre um conjunto curto de traces. Só esse recorte já mostra onde o runtime simplifica a operação.
Para quem está implementando em ambiente real, o ganho está em transformar “debug manual” em “ciclo repetível”. É a diferença entre corrigir um comportamento isolado e construir um processo que consegue acompanhar a evolução do agente ao longo do tempo.
Conclusão
Interactive Shells tornam o AgentCore Runtime mais útil para investigação, depuração e manutenção de contexto dentro da própria sessão. O loop de performance fecha a outra ponta: observação, avaliação, validação em lote e teste em tráfego real com evidência estatística. Juntos, esses recursos transformam manutenção de agentes de um trabalho quase artesanal em um processo que dá para repetir e auditar.
Se você quiser aplicar isso hoje, abra a documentação oficial, compare o fluxo de terminal persistente com a execução one-shot e desenhe um pequeno ciclo de avaliação para um caso seu — por exemplo, um prompt, uma tool ou uma rota de agente que dá mais suporte ao time. Em menos de uma hora, dá para sair da leitura para um primeiro teste local de arquitetura.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para construir soluções com Amazon Bedrock, agentes autônomos e automação de fluxos na AWS.
- Formação AWS Cloud Foundations — base para quem quer entender os fundamentos de cloud e os principais serviços da AWS usados em arquiteturas modernas.
- Jornada DevOps com AWS - Impulso — trilha focada em Linux, Docker, Kubernetes e AWS para fortalecer automação e entrega contínua.
- Cloud DevOps Experience - Banco Carrefour — bootcamp voltado a práticas de DevOps e cloud com contexto de mercado e projeto aplicado.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
