Pode fechar o notebook agora: hospedando agentes de código no Amazon Bedrock AgentCore

Existe um hábito que virou rotina entre desenvolvedores que usam agentes de IA: andar de reunião em reunião com o notebook entreaberto, sentar em uma conversa individual com a tela ligada só para o agente não morrer, ou voltar para casa segurando o computador porque fechar a tampa significa encerrar a sessão do agente. O Business Insider já reportou esse comportamento. A causa é simples: agentes como Claude Code, Codex, Kiro, OpenCode, Gemini CLI e Cursor CLI precisam de cinco coisas para funcionar — um shell, um sistema de arquivos, o projeto clonado, as dependências instaladas e as permissões certas. O notebook do desenvolvedor tem tudo isso. O problema é que ele nunca foi a máquina certa para o trabalho; apenas a mais próxima.

O Amazon Bedrock AgentCore Runtime foi lançado justamente para resolver isso: cada sessão recebe um ambiente dedicado — uma microVM Linux isolada com workspace persistente, shell real e execução determinística de comandos. O que diferencia o AgentCore de produtos similares de sandbox é o ecossistema que vem junto: uma camada de Identity que faz o agente agir como o usuário que o acionou, um Gateway que expõe GitHub, Jira, Slack e serviços próprios via um único endpoint Protocolo de Contexto de Modelo (MCP), com tokens reais armazenados fora do agente, e Observability que registra cada passo do agente no Amazon CloudWatch já utilizado pela equipe.

Por que o notebook é o host errado

Antes de entrar nas capacidades do AgentCore, vale entender por que o notebook nunca deveria ter assumido esse papel. Quatro razões se destacam:

• O notebook é sua zona de impacto. O agente compartilha seu shell, seu sistema de arquivos, seus tokens, sua VPN e suas chaves SSH carregadas. Um README com prompt injection malicioso é um vetor de ataque real.
• Segredos ficam ao lado do código editado. Arquivos .env, ~/.aws/credentials, ~/.ssh/id_ed25519 e tokens de registros privados ficam acessíveis no mesmo shell que o agente usa. O princípio do menor privilégio não está sendo respeitado.
• git worktree é uma solução parcial para paralelismo. Rodar dois agentes em paralelo com worktrees ainda significa dois processos brigando pelo mesmo host: mesmo Postgres em localhost:5432, mesmo servidor de desenvolvimento na porta :3000, mesmo keyring SSH, mesmas credenciais AWS. Três agentes em três branches equivalem a três processos em conflito numa única máquina.
• A tampa do notebook é o interruptor de emergência. Suspender o computador suspende o agente. Fechar para uma reunião mata a sessão. Um refactor de 90 minutos ou uma migração noturna exige que a tampa fique aberta por todo esse tempo. Entregar uma funcionalidade não deveria depender do ângulo da dobradiça de um notebook.

O que desenvolvedores e times de plataforma precisam

Do ponto de vista do desenvolvedor, a necessidade é clara: a mesma experiência do notebook, sem as limitações. Mesmo agente, mesmo shell, mesmo sistema de arquivos, mesmo feedback imediato — mas com a possibilidade de fechar a tampa, rodar múltiplos agentes em paralelo e manter o trabalho mesmo após uma reinicialização ou um voo longo.

Para times de plataforma, os requisitos são os de sempre: cada agente com seu próprio escopo, tráfego dentro da Nuvem Privada Virtual (VPC), identidade vinculada ao provedor de identidade (IdP) corporativo, registros no AWS CloudTrail, rastreamentos no CloudWatch, acesso a ferramentas mediado por política e credenciais que nunca ficam em disco dentro de um ambiente controlado por um Modelo de Linguagem Grande (LLM). Nada disso deveria ser opcional, e nenhum desses requisitos deveria exigir construção manual.

Traga qualquer agente, qualquer modelo, rode em paralelo

O AgentCore Runtime aceita Claude Code, Codex, Kiro, OpenCode, Cursor CLI, Gemini CLI ou qualquer harness próprio empacotado em container ou .zip. O container vai para o Amazon Registro de Container Elástico (ECR) ou o projeto Python / Node.js é implantado diretamente via zip. A imagem pode incluir todas as dependências necessárias: runtimes de linguagem, ferramentas de build, git e pacotes do sistema.

O Runtime é agnóstico de modelo. O harness escolhe o modelo e o caminho para chegar até ele. Há três rotas possíveis:

• Via Amazon Bedrock, que hospeda a família Claude da Anthropic, modelos OpenAI e outros como Nova, Llama, Mistral, Qwen e Kimi.
• Diretamente via provedor: API da Anthropic, API da OpenAI, Google e outros ainda são acessíveis via HTTPS.
• Via gateway LLM próprio, para quem já padronizou em uma solução interna de roteamento, fallback e controle de custos.

A rota pelo Amazon Bedrock tem uma propriedade importante: prompts, tokens e outputs não saem da rede AWS — exatamente o que times de segurança costumam perguntar primeiro.

Cada sessão roda em sua própria microVM Firecracker. É possível iniciar N sessões em segundos, rodar o mesmo agente contra dez branches ou colocar três agentes diferentes trabalhando no mesmo ticket e comparar quem performa melhor — sem colisões de localhost:5432, sem conflitos de filesystem.

As quatro capacidades que transformam um container em ambiente de desenvolvimento real

1. Workspace persistente em /mnt/workspace

O armazenamento gerenciado de sessão (em prévia pública) oferece um diretório persistente sem configuração. O agente escreve arquivos; eles estão lá na próxima vez. node_modules, .git, caches de build, o refactor pela metade: tudo disponível exatamente como foi deixado. Quando a microVM fica ociosa, o filesystem permanece. Ao retomar com o mesmo ID de sessão, uma nova microVM monta o mesmo filesystem em milissegundos. Os dados ficam disponíveis por 14 dias de inatividade.

client.create_agent_runtime(
    agentRuntimeName="acme-coding-agent",
    agentRuntimeArtifact={"containerConfiguration": {"containerUri": "..."}},
    filesystemConfigurations=[
        {"sessionStorage": {"mountPath": "/mnt/workspace"}}
    ],
    roleArn="arn:aws:iam::...:role/AgentExecutionRole",
)

No notebook, a alternativa seria usar git worktree (veja a documentação) para isolamento lógico entre sessões de agentes. No AgentCore, o isolamento é físico: cada agente aponta para uma microVM isolada com seu próprio /mnt/workspace, caches de build e estado de filesystem separados. Nenhum gerenciamento de worktree necessário.

2. Shell interativo real

A partir de 5 de junho, o AgentCore Runtime introduziu shells interativos para acesso terminal às sessões de agentes. O comando agentcore exec --it abre um shell com suporte a PTY direto na microVM em execução — com cores, tab completion, Ctrl+C, redimensionamento de terminal e reconexão automática em caso de queda de rede.

Cada sessão interativa tem dois IDs relevantes: o ID de sessão do runtime (qual microVM) e o ID do shell (qual shell dentro da microVM). Passando ambos para agentcore exec --it, o desenvolvedor cai no mesmo shell, mesmo diretório de trabalho, mesmo scrollback — sem boot, sem re-clone.

# Entrar na VM do agente
agentcore exec --it --runtime acme-coding-agent --session-id sess-jane-1234

# Reconectar ao mesmo shell depois
agentcore exec --it --session-id sess-jane-1234 --shell-id shell-789

3. Execução determinística de comandos pela camada de aplicação

O terminal não é a única forma de controlar o ambiente. Para operações já determinísticas — rodar a suíte de testes, fazer push de uma branch, instalar uma dependência, buscar um dataset — é possível pular o modelo completamente. O InvokeAgentRuntimeCommand envia comandos shell direto para a microVM, transmitindo stdout/stderr de volta via HTTP/2. Sem gasto de tokens, sem decisão probabilística sobre se o push aconteceu.

# Execução não-interativa
agentcore exec --runtime acme-coding-agent --session-id sess-jane-1234 \
  "cd /mnt/workspace && npm test"

4. Filesystems próprios para skills, caches e artefatos compartilhados

O armazenamento gerenciado de sessão cobre a persistência por sessão. Para dados compartilhados entre sessões e agentes — biblioteca de Skills da equipe, cache de dependências, artefatos de pipelines anteriores — é possível montar Amazon Serviço de Armazenamento Simples (S3) Files ou pontos de acesso do Amazon Sistema de Arquivos Elástico (EFS) como diretórios POSIX dentro de cada sessão. Até cinco montagens por runtime, sem sidecars, helpers ou /etc/fstab.

filesystemConfigurations=[
    {"sessionStorage": {"mountPath": "/mnt/workspace"}},
    {"s3FilesAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/skills"}},
    {"efsAccessPoint": {"accessPointArn": "...", "mountPath": "/mnt/cache"}},
]

Ferramentas e credenciais do jeito certo

Um agente de código que só edita arquivos tem vida curta. Em algum momento ele precisa abrir um pull request, comentar em um ticket do Jira, fazer push em um registro privado ou notificar alguém no Slack. A abordagem errada é colocar credenciais do GitHub (ou qualquer token de acesso) dentro do ~/.netrc da microVM. A abordagem certa é nunca colocá-las lá.

O AgentCore Gateway é onde o catálogo de ferramentas fica, e o AgentCore Identity guarda as credenciais por trás: segredos de longa duração no AWS Secrets Manager, tokens de curta duração cacheados no Token Vault. As ferramentas que um agente de código precisa (GitHub, Jira, Slack, sistema de build, serviços próprios via OpenAPI ou AWS Lambda) são registradas uma vez, e o Gateway expõe um único endpoint MCP que Claude Code, Codex, Cursor, Kiro e OpenCode já utilizam. A configuração no harness é uma linha de MCP config:

# Claude Code
claude mcp add agentcore \
  https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  --transport http

# Codex CLI
~/.codex/config.toml
[mcp_servers.agentcore]
url = "https://<gateway-id>.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"

Três padrões cobrem a maioria dos fluxos de trabalho de coding:

• Padrão bot: para agentes agindo por conta própria. Um bot do GitHub é criado, um token de acesso pessoal (PAT) com escopo fino é registrado como credencial no Gateway. O Identity guarda o PAT no Token Vault e o Gateway o anexa a cada chamada.
• Padrão on-behalf-of: para agentes agindo como uma pessoa. O desenvolvedor faz login via IdP. O Identity gera um token de acesso de workload e o troca por um com escopo GitHub usando OAuth 2.0 Token Exchange (RFC 8693). PRs são atribuídos ao humano, não a um bot compartilhado. O mesmo fluxo funciona para Jira, Slack, Salesforce ou Confluence.
• Padrão broker: para casos que exigem controle total do fluxo de credenciais — como tokens de instalação de GitHub App que precisam de JWT auto-assinado, ou serviços que não federam com o IdP. O target do Gateway aponta para uma Lambda que gera ou busca a credencial por chamada, faz proxy da requisição e nunca retorna o segredo ao agente.

Uma operação que o servidor MCP do GitHub não consegue fazer é clonar um repositório privado. O clone inicial ainda passa pelo git, que precisa de uma credencial na sessão. A recomendação da AWS é manter essa credencial com escopo mínimo — um PAT read-only nos repos permitidos ou uma deploy key vinculada a um repo. O valor fica no Secrets Manager por trás de um provedor de credenciais do Identity, e no início da sessão o runtime busca o valor, usa uma vez para o git clone, e todas as ações seguintes no GitHub fluem pelo Gateway.

Para operações de shell que falam direto com a internet — npm install, git clone, cargo build, pip install — o Gateway não vê esse tráfego. A rede subjacente sim. Agentes hospedados no AgentCore Runtime podem viver dentro da VPC, o que significa que a equipe decide o que “internet” significa a partir de dentro da microVM: resolução de DNS para registros internos, regras de security group que bloqueiam pushes para repositórios não autorizados no nível TCP, e AWS Network Firewall com allowlist de domínios na frente do gateway NAT. Para saber mais sobre controle de domínios, a AWS publicou um guia: Controle quais domínios seus agentes de IA podem acessar.

Observabilidade, ciclo de vida e rede

Toda invocação cai no AWS CloudTrail. Cada sessão envia rastreamentos OpenTelemetry para o Amazon CloudWatch, com métricas integradas de contagem de sessões, latência, duração, uso de tokens e taxas de erro — visíveis no dashboard CloudWatch GenAI Observability. Para ferramentas que não falam OTel nativamente, como o Claude Code, é possível incluir o coletor AWS Distro for OpenTelemetry (ADOT) como sidecar no container.

Cada microVM pode rodar por até 8 horas, ou apenas um minuto. Quando uma sessão fica ociosa além do idleRuntimeSessionTimeout (15 minutos por padrão, configurável), o compute encerra sozinho. Para encerrar antes, o StopRuntimeSession termina a microVM imediatamente. Em ambos os casos, /mnt/workspace, S3 Files e EFS permanecem onde estão. O modelo de cobrança rastreia o consumo real de CPU (I/O wait não tem custo adicional) e o pico de memória utilizado. É possível rodar centenas de sessões em paralelo e pagar apenas pelos recursos que cada uma realmente consome.

Quem já está usando

Várias equipes já rodam agentes de código e outros tipos de agentes no AgentCore. A Thomson Reuters usa o AgentCore para hospedar o CoCounsel, seu assistente de IA para fluxos jurídicos de alto risco, construído sobre o Claude Agent SDK — a mesma base do Claude Code. A empresa cita a infraestrutura escalável e segura como o que permite ao time focar na construção de sistemas de IA confiáveis para clientes.

A Iberdrola roda workloads LangGraph para operações de TI dentro de sua VPC, com Runtime, Identity, Memory e gateways MCP. A Cox Automotive foi de zero experiência com agentes a produção em um mês, rodando 17 agentes com permissões gerenciadas pelo Identity. A Druva coordena de oito a dez agentes especializados em cibersegurança no Runtime, com o Identity delimitando o escopo de cada agente (dados, ajuda, ação) sem frear o time de desenvolvimento. A Kollab hospeda seu workspace de IA no AgentCore Runtime, com o armazenamento gerenciado de sessão mantendo o diretório de trabalho montado entre pausas — inclusive para tarefas agendadas que acumulam estado entre execuções diárias. A equipe de Platform Engineering da Thomson Reuters também construiu um hub agêntico no AgentCore que automatiza provisionamento de contas cloud, patching de banco de dados e revisão de arquitetura, reportando ganho de produtividade de 15x no lançamento.

Uma frota de agentes trabalhando em paralelo

O repositório GitHub de acompanhamento transforma o conceito em três experimentos executáveis. Cada um começa da mesma forma: a aplicação chama o AgentCore Runtime uma vez por agente, cada chamada cai em sua própria microVM, e a partir daí cada agente trabalha em sua própria cópia do projeto.

• Race — quem corrige primeiro? Um issue do GitHub é enviado para quatro agentes ao mesmo tempo. Cada um roda em sua própria microVM e abre o PR via Gateway. Os competidores são Claude Code, Codex CLI, Kiro CLI e Cursor CLI.
• Bench — quem corrige melhor? Mesma configuração, mas em vez de declarar um vencedor, o script avalia todos. Latência, custo em dólar e taxa de aprovação nos testes por execução são gravados em CSV. Ao repetir com diferentes combinações de modelo × harness, a pergunta “qual modelo é melhor para nossa base de código?” passa a ter resposta baseada em dados.
• Watch — acompanhar o agente de perto. Um agente de refactor de longa duração, duas horas, rodando sem supervisão. Enquanto trabalha, o desenvolvedor abre um terminal localmente e executa agentcore exec --it contra a mesma sessão — entrando na mesma microVM que o agente, podendo acompanhar logs, ler stack traces ou deixar uma nota em um arquivo que o agente relê no próximo passo.

AGENTS = {
    "claude-code": {
        "name": "Claude Code",
        "config_dir": os.path.join(AGENTS_DIR, "claude-code"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "global.anthropic.claude-opus-4-8",  # Opus 4.8
    },
    "kiro": {
        "name": "Kiro",
        "config_dir": os.path.join(AGENTS_DIR, "kiro"),
        "run_cmd": "/app/run.sh {model_flag}chat '{prompt}'; exit",
        "default_model": "auto",  # Automatic model option from Kiro
    },
    "codex": {
        "name": "Codex",
        "config_dir": os.path.join(AGENTS_DIR, "codex"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "openai.gpt-5.5",  # GPT 5.5
    },
    "hermes": {
        "name": "Hermes",
        "config_dir": os.path.join(AGENTS_DIR, "hermes"),
        "run_cmd": "/app/run.sh {model_flag}'{prompt}'; exit",
        "default_model": "global.meta.llama4-maverick-17b-instruct-v1:0",  # Llama model
    }
}

A invocação pode ser feita de forma não-interativa:

client.invoke_agent_runtime_command(
    agentRuntimeArn=ARN,
    runtimeSessionId=sid,
    body={"command": "cd /mnt/workspace && npm test", "timeout": 300},
)

Ou de forma interativa no terminal:

client.invoke_agent_runtime_command_shell(
    agentRuntimeArn=ARN,
    runtimeSessionId=sid
)

O resultado é múltiplas abas, múltiplas janelas, cada uma conectada a uma microVM diferente. O notebook deixa de fazer o trabalho e passa a ser o ponto de supervisão de uma frota de agentes.

Recursos adicionais

• Repositório GitHub de acompanhamento
• Exemplo de SDLC assistido por agente
• Documentação do AgentCore Runtime
• Documentação do AgentCore Gateway
• Documentação do AgentCore Identity
• Documentação do AgentCore Observability
• Preços

Fonte

It’s safe to close your laptop now: Hosting coding agents on Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/)