AWS Bedrock AgentCore Runtime ganha shell interativa
TL;DR
Em junho de 2026, o Amazon Bedrock AgentCore Runtime passou a oferecer shells interativas persistentes, com terminal PTY acessado por WebSocket. Na prática, isso permite manter estado entre comandos, retomar sessão após desconexão e depurar agentes com uma experiência mais próxima de um terminal remoto real.
A mudança é especialmente relevante para coding agents e fluxos de automação que precisam inspecionar arquivos, rodar comandos ad hoc e preservar contexto de execução. Para times no Brasil, isso conversa direto com cenários de entrega em cloud, onde custo, latência e padronização de ambiente fazem diferença no dia a dia.
O que mudou no AgentCore Runtime
O update de junho de 2026 adiciona a operação InvokeAgentRuntimeCommandShell, que abre um terminal interativo persistente dentro de uma sessão do AgentCore Runtime. A documentação descreve esse terminal como uma shell baseada em PTY, conectada por WebSocket, com entrada e saída em tempo real. Fonte: Interactive Shells (Terminals) - Amazon Bedrock AgentCore e Amazon Bedrock AgentCore Runtime introduces interactive shells for terminal access into agent sessions.
Essa diferença importa porque o fluxo deixa de ser apenas “manda um comando e espera a resposta”. Agora o runtime pode sustentar uma sessão com histórico, diretório de trabalho e variáveis de ambiente preservados entre interações. Isso é útil quando o agente precisa iterar sobre o mesmo workspace, repetir inspeções e manter dependências já carregadas. Fonte: Interactive Shells (Terminals) - Amazon Bedrock AgentCore.
Shell one-shot versus shell persistente
A documentação também explicita a diferença entre a execução de shell “one-shot” e a shell persistente. No modelo stateless, cada comando tende a começar do zero; no modelo interativo, o estado é preservado e pode ser reaproveitado pela conversa seguinte. Fonte: Shell execution - Amazon Bedrock AgentCore.
Esse detalhe é importante para quem constrói agentes que operam como assistentes de desenvolvimento. Se o agente precisa executar um cd, exportar variáveis, instalar dependências ou navegar por um código-fonte, a persistência evita que cada passo dependa de reconfiguração manual. Em vez de transformar tudo em uma sequência rígida de chamadas, o runtime passa a se comportar mais como uma sessão de trabalho contínua.
Esta seção descreve a versão de junho de 2026 do runtime AgentCore. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Reconexão, estado e concorrência
Outro ponto prático é a reconexão. A doc informa que a shell pode ser retomada usando session_id e shellId, o que ajuda quando há queda de rede, timeout da interface ou troca de aba no cliente. Em vez de perder o contexto, o usuário volta para a mesma sessão e continua de onde parou. Fonte: Interactive Shells (Terminals) - Amazon Bedrock AgentCore.
Há também um limite explícito de concorrência: até 10 shells por runtime. Isso sugere um uso deliberado de terminais paralelos em cenários de inspeção, depuração ou workflows com múltiplas tarefas. Em uma interface tipo IDE web, por exemplo, o time pode abrir shells separadas para testar componentes diferentes sem trocar de contexto o tempo todo. Fonte: Interactive Shells (Terminals) - Amazon Bedrock AgentCore.
Por que isso importa para agentes de código
O anúncio da AWS enquadra a novidade como uma capacidade útil para coding agents, citando o uso do terminal para inspecionar arquivos, rodar comandos ad hoc e debugar o ambiente. Isso reduz a distância entre a intenção do agente e a ação executada no sistema, algo relevante quando o objetivo é testar, ajustar e validar comportamento em tempo real. Fonte: Amazon Bedrock AgentCore Runtime introduces interactive shells for terminal access into agent sessions.
Na prática, a shell persistente serve como uma camada de observabilidade operacional. Em vez de o agente só devolver uma resposta textual, ele pode navegar no workspace, checar dependências, reproduzir um erro e continuar a investigação na mesma sessão. Isso é especialmente valioso em integrações com ferramentas de engenharia de software, onde o estado do ambiente determina o próximo passo.
Exemplo de fluxo prático
Um fluxo plausível para um agente de desenvolvimento seria: abrir a shell, posicionar o diretório de trabalho, validar variáveis de ambiente, executar uma suíte de testes e, se houver erro, manter a mesma sessão para investigar logs e repetir o comando com ajustes. O ganho não está em “automatizar tudo”, mas em reduzir o atrito entre correção incremental e contexto persistente.
Esse padrão é familiar para qualquer pessoa que já depurou um serviço remoto via terminal interativo. A diferença aqui é que o terminal passa a ser parte do runtime do agente, não apenas uma ferramenta ao lado dele.
Por que importa pro dev brasileiro
No Brasil, esse tipo de recurso conversa diretamente com equipes que trabalham com cloud e automação sob restrição de custo e latência. Muitas operações de produto ainda rodam em regiões da AWS fora do país, como AWS Regions, o que torna desconexões, back-and-forth com ambiente e janelas de troubleshooting mais sensíveis na rotina. Quando a sessão preserva estado, o time gasta menos tempo repetindo setup e mais tempo resolvendo o problema real.
Há também um ponto de LGPD: quando o agente precisa depurar dados, logs ou fluxos que tocam informação pessoal, manter o processo dentro de uma sessão controlada e reproduzível ajuda a reduzir improviso operacional. Isso não resolve compliance sozinho, mas facilita auditoria técnica e padronização de acesso, algo importante em empresas brasileiras que lidam com bases de clientes, fintechs, varejo e saúde. Para times que já operam com prazos curtos e orçamento em BRL, menos retrabalho significa menos custo de engenharia.
Como pensar adoção com segurança
A primeira decisão é separar casos de uso stateless de casos realmente interativos. Se a tarefa é gerar uma resposta única, a shell persistente pode ser excesso; se há depuração, instalação de dependências, navegação de arquivos e repetição de passos, o terminal interativo faz sentido. A doc de shell execution ajuda a fazer essa triagem conceitual. Fonte: Shell execution - Amazon Bedrock AgentCore.
A segunda decisão é observar governança de sessão. Como o terminal mantém estado, o desenho do fluxo precisa considerar expiração, reconexão e controle de concorrência. Para times brasileiros que já trabalham com pipelines em AWS, isso se encaixa bem em práticas de ambientação por workspace, logs centralizados e revisão de comandos executados.
Se o objetivo for construir uma experiência parecida com um terminal remoto para agentes, o agente precisa também de limites claros: quais comandos podem ser executados, quais diretórios são permitidos e como tratar segredos. O update da AWS fornece a superfície; a segurança continua sendo responsabilidade da aplicação que usa a superfície.
Conclusão
O update de junho de 2026 muda o AgentCore Runtime de uma base só de execução para uma base com interação de shell persistente. Isso aproxima o runtime de um modelo mais útil para agentes que precisam debugar, explorar estado e trabalhar sobre o mesmo ambiente ao longo de várias trocas.
Se você já estuda ou usa AWS em projetos de IA, vale comparar seu fluxo atual com a nova shell interativa e identificar onde o estado persistente elimina retrabalho. Uma ação prática para a próxima hora: abra a documentação oficial do Interactive Shells e mapeie um caso do seu projeto em que um terminal com reconexão e estado reduziria passos manuais.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para criar soluções com Amazon Bedrock, agentes autônomos e automação em cenários reais de IA generativa.
- Nexa - Fundamentos de IA Generativa com Bedrock — jornada curta para entender Bedrock, Amazon Nova e AgentCore aplicados a projetos com IA generativa.
- Formação AWS Cloud Foundations — base para quem quer consolidar fundamentos de cloud na AWS antes de avançar para serviços mais especializados.
- Jornada DevOps com AWS - Impulso — foco em Linux, Docker, Kubernetes e AWS para quem une automação, infraestrutura e entrega contínua.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
