Agentes de IA com Bedrock AgentCore: o que a AWS assume

Vale testar o Amazon Bedrock AgentCore em um piloto quando seus agentes de IA já funcionam, mas a infraestrutura ao redor começa a virar um segundo produto. O catálogo atual da AWS reúne 13 serviços e recursos modulares. Adote os que resolvem uma dificuldade operacional bem definida e mantenha sob sua responsabilidade o comportamento do agente nas tarefas de negócio.

Informações conferidas na página oficial do produto e na documentação da AWS em 30 de outubro de 2026. A lista de componentes abaixo vem da visão geral para desenvolvedores, indicada na página do AgentCore. O mapeamento do que cada componente substitui é uma análise de engenharia deste artigo.

O que é o Amazon Bedrock AgentCore?

O AgentCore permite delegar à AWS partes específicas da operação de agentes em produção. Um agente é um software que usa um modelo para escolher ações, acionar ferramentas e avançar em uma tarefa. Fazer esse ciclo funcionar localmente ainda deixa bastante trabalho de identidade, execução, estado, controle de acesso e depuração.

Pense em uma sala de concertos. O comportamento do agente é a apresentação. Runtime fornece o palco e a infraestrutura de apoio; os controles de acesso cuidam das portas; a memória preserva o contexto útil; a observabilidade registra o que aconteceu. Continua sendo sua a decisão sobre o que a apresentação deve entregar e se ela cumpriu o objetivo.

A AWS apresenta o AgentCore como compatível com qualquer framework e qualquer modelo: “Any framework. Any model.” A página do produto cita LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK e frameworks próprios. Esse é o escopo que a AWS declara para a plataforma. Não significa que todos os recursos opcionais tenham as mesmas integrações ou que uma migração dispense trabalho. Visão geral do produto na AWS.

Também há caminhos distintos para definir quem fica responsável pelo ciclo de execução. Com Runtime, você implanta o código do seu agente. Com Harness, descreve o agente por configuração e usa o ciclo gerenciado pela AWS, baseado em Strands Agents, o framework de agentes de código aberto da empresa. A documentação do Harness explicita essa diferença. Quem lidera uma equipe de engenharia que já tem código de orquestração funcionando deve avaliar primeiro o caminho com Runtime.

Bedrock Agents ou AgentCore: qual é a diferença?

Uma aplicação que já usa Amazon Bedrock Agents não precisa migrar só porque o AgentCore existe. A AWS afirma que os usuários atuais do Bedrock Agents podem continuar usando o serviço. Faz sentido avaliar o AgentCore quando há uma necessidade específica de seus recursos de execução, integração ou operação. Perguntas frequentes da AWS.

A distinção útil agora vai além de “ciclo gerenciado versus infraestrutura”. O AgentCore também oferece um ciclo gerenciado por meio do Harness. Primeiro, decida se quer manter o controle do código de orquestração; depois, escolha o caminho correspondente. Use a visão mais ampla do mapa de arquitetura de agentes de IA para orientar essa decisão, evitando que uma escolha de hospedagem acabe redesenhando toda a aplicação sem intenção.

Componentes do Bedrock AgentCore: o que cada um substitui?

Escolha os componentes pelo trabalho que, sem eles, sua equipe teria de desenvolver e operar. A AWS os documenta como recursos modulares, que podem funcionar juntos ou de forma independente. A última coluna mostra as responsabilidades que continuam na aplicação, mesmo quando a AWS fornece o serviço de apoio.

Um assistente de atendimento pode precisar de Runtime, Gateway e Identity de imediato, e de Memory quando o contexto de usuários recorrentes passar a ser útil. Payments não tem função se o assistente nunca compra acesso a um recurso externo. Registry passa a ajudar quando encontrar recursos aprovados dentro da organização se torna um problema. Adotar mais componentes não é uma meta em si.

Code Interpreter e Runtime resolvem tarefas diferentes. Runtime hospeda o agente; Code Interpreter fornece um sandbox para o código que o agente executa. Se a única lacuna for a execução isolada de código, compare as opções no guia de sandboxes de código para agentes de IA antes de mover sua orquestração.

Arquitetura de agentes de IA: quais decisões continuam com sua equipe?

É preciso delimitar o que cabe à infraestrutura gerenciada e o que cabe à aplicação autorizar. Em um exemplo de fluxo de atendimento, o agente poderia consultar um pedido, explicar seu status e propor uma ação. A AWS pode fornecer a infraestrutura de execução e acesso, mas sua aplicação precisa determinar de quem é o pedido e se aquela ação é permitida.

Bedrock AgentCore Runtime: isolamento não define a quem pertence a sessão

Runtime pode isolar a execução sem saber a qual cliente uma sessão pertence. A AWS documenta ambientes de microVM dedicados às sessões, com separação de recursos computacionais, memória e sistema de arquivos. A mesma documentação afirma explicitamente que o AgentCore não impõe o vínculo entre sessões e usuários; o backend da aplicação cliente precisa manter essa relação. Sessões do Runtime.

No assistente de atendimento, não aceite um identificador de sessão enviado pelo navegador como prova de que ela pertence ao cliente. Autentique a requisição, identifique a sessão permitida no backend e restrinja os acessos subsequentes aos dados desse cliente. O isolamento da infraestrutura e a decisão de autorização da aplicação são responsabilidades distintas.

Bedrock AgentCore Memory: escolha o que vale guardar

Memory substitui a infraestrutura de gerenciamento de contexto; você decide o que deve entrar nela. A AWS oferece suporte ao contexto de curto prazo das conversas e a informações de longo prazo mantidas entre sessões. Documentação do Memory.

Lembrar que um cliente prefere respostas curtas é diferente de armazenar o saldo oficial de um pedido. Mantenha os registros de negócio da aplicação como fonte de verdade. Defina como o agente consulta dados atualizados, quais informações da conversa pode reter e o que acontece quando uma preferência lembrada deixa de valer. Um serviço de memória não toma essas decisões de modelagem de dados por você.

Bedrock AgentCore e MCP: Gateway faz a conexão

Gateway é útil quando conectar ferramentas se torna um trabalho repetitivo de engenharia. Model Context Protocol, ou MCP, é uma interface comum para disponibilizar ferramentas a agentes. Gateway pode transformar APIs e funções AWS Lambda em ferramentas compatíveis com MCP e se conectar a servidores MCP existentes. Sua documentação atual também contempla o roteamento para outros agentes e modelos. Documentação do Gateway.

Para um assistente de pedidos, disponibilize primeiro uma operação restrita, como consultar o status de entrega, antes de oferecer uma ferramenta genérica de consulta ao banco de dados. Gateway pode encaminhar a chamada; sua API continua definindo o significado da operação, quais registros ela pode acessar e se uma nova tentativa pode repetir um efeito colateral.

Bedrock AgentCore Identity: credenciais precisam de regras de negócio

Identity cuida de quem executa a ação e das credenciais usadas; Policy controla as ações permitidas no gateway. Identity fornece identidade para cargas de trabalho e gerenciamento de credenciais de acesso a recursos da AWS e serviços de terceiros, inclusive para agir em nome de um usuário. Documentação do Identity.

Policy avalia o tráfego que passa por um AgentCore Gateway associado antes de permitir o acesso às ferramentas. Esse limite importa: não presuma que uma política do gateway controle uma chamada direta de rede que o agente faça por outro caminho. Encaminhe as operações sensíveis pelo ponto de controle previsto e restrinja os caminhos que permitem contorná-lo. Documentação do Policy.

Uma identidade de atendimento ao cliente pode ter permissão para consultar um pedido, mas não para emitir um reembolso. As instruções do modelo devem descrever esse fluxo, enquanto as camadas de ferramentas e autorização fazem valer a permissão.

Bedrock AgentCore Observability: o que um trace realmente comprova?

Observability ajuda a reconstituir o comportamento; Evaluations ajuda a avaliá-lo. O AgentCore oferece visualizações da execução e telemetria compatível com OpenTelemetry, um formato padronizado para traces e métricas, com dashboards baseados no Amazon CloudWatch. A AWS distingue as métricas nativas dos traces adicionais e dos metadados de negócio que sua equipe instrumenta na aplicação. Documentação do Observability.

No assistente de atendimento, registre se a consulta ao pedido solicitado foi concluída e se uma ação recebeu aprovação. Uma chamada de ferramenta tecnicamente bem-sucedida ainda pode responder à pergunta de negócio errada.

Evaluations oferece avaliações nativas e personalizadas, inclusive com modelos atuando como avaliadores. Defina seus próprios casos representativos e revise as falhas com consequências relevantes. A documentação de avaliações especifica os caminhos de framework e instrumentação compatíveis; verifique o caminho escolhido, sem estender a promessa ampla de compatibilidade da plataforma a todos os recursos.

Quais limites mudam o projeto?

Separe a vida útil dos recursos computacionais da vida útil do estado que precisa ser preservado. A documentação atual da AWS sobre ciclo de vida especifica um tempo limite padrão de inatividade de 15 minutos e uma duração máxima de 8 horas para os recursos computacionais de uma microVM. Instances, a alternativa que executa capacidade gerenciada do Amazon Elastic Compute Cloud na sua conta, permite configurar uma duração de até 14 dias, sujeita às configurações do provedor de capacidade. Configurações de ciclo de vida, Instances.

Uma sessão lógica pode ser retomada em recursos computacionais recém-provisionados. Por padrão, o estado em memória e no sistema de arquivos local acompanha o ciclo de vida desses recursos. Com o armazenamento de sessão configurado, é possível preservar os dados do sistema de arquivos entre interrupções e retomadas. Planeje explicitamente o que precisa sobreviver a uma interrupção. Ciclo de vida e armazenamento de sessões.

Antes de definir o conjunto de recursos, consulte a matriz de recursos por região da AWS. Estar “disponível na AWS” não basta para uma aplicação vinculada a uma região específica.

Quando vale a pena usar AgentCore?

Avance quando uma lacuna operacional bem definida estiver impedindo a entrega e o componente gerenciado correspondente atender aos requisitos. Avalie a escolha pelo isolamento da execução, pelo acesso autorizado às ferramentas, pela preservação de estado, pela facilidade de diagnóstico e pelo trabalho de operar esses recursos por conta própria.

Para quem desenvolve, comece um piloto quando a lógica do agente já funciona, mas ainda depende de hospedagem ou integração com ferramentas. Manter o ciclo existente no Runtime torna o experimento mais delimitado do que trocar ao mesmo tempo o framework e a plataforma de implantação.

Para quem opera, o argumento fica mais forte quando todos os agentes precisam do mesmo gerenciamento de credenciais, controle de acesso e investigação de incidentes. Escolha um fluxo que permita demonstrar essas responsabilidades, incluindo uma falha que precise ser diagnosticada.

Para quem decide a contratação em engenharia, a pergunta é qual trabalho recorrente deixa de existir e qual novo trabalho de integração permanece. Configuração da AWS, desenho de permissões, comportamento da aplicação e resposta a incidentes de plantão continuam precisando de responsáveis definidos.

Espere se a stack atual já oferece os controles necessários e não há um problema concreto a resolver. A migração precisaria de outro motivo, como um recurso que sua stack não consegue fornecer. Siga como está se o fluxo for uma sequência fixa de operações conhecidas e não precisar de um agente para escolher a próxima ação.

Se o custo determinar a decisão, consulte os preços do AgentCore na AWS junto com o guia de preços do Amazon Bedrock do site.

Como fazer o primeiro piloto com a CLI da AWS?

Comece pelo template da AWS baseado em código e acrescente uma operação de negócio representativa. Este caminho segue o guia de início rápido do Runtime e o guia completo da CLI atuais. O roteiro foi elaborado a partir da documentação; a implantação não foi testada para este artigo.

O guia completo exige Node.js 20.12 ou posterior, npm, Python 3.10 ou posterior, o gerenciador de dependências Python uv, credenciais da AWS configuradas, permissões de implantação e acesso a modelos. O template usa CodeZip, portanto não é necessário usar Docker.

1. 1

   Instale e crie a estrutura do projeto

   Use uma conta ou um ambiente de desenvolvimento da AWS.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   O template inclui um Runtime chamado agent e um recurso AgentCore Memory. Revise ambos na configuração gerada.

2. 2

   Teste localmente

   cd MyProject
   agentcore dev --mode browser

   Teste o agente no inspetor local e pare o servidor antes de continuar no mesmo terminal.

3. 3

   Faça o build, implante e invoque

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   A implantação provisiona recursos da AWS por meio do AWS Cloud Development Kit, ou CDK.

4. 4

   Inspecione e remova os recursos

   agentcore logs runtime
   agentcore traces runtime list

   No diretório deste projeto piloto, os comandos abaixo removem seus recursos e desmontam a stack implantada:

   agentcore remove all --yes
   agentcore deploy --yes

Antes de receber tráfego de produção, substitua a saudação por uma tarefa delimitada, como consultar um pedido de teste. As verificações de aceitação recomendadas dependem da aplicação: retorno dos dados corretos, rejeição de acessos não autorizados, visibilidade de uma chamada de ferramenta malsucedida no trace e compreensão da recuperação após uma interrupção. São critérios de decisão para o seu piloto, não promessas de desempenho da AWS.

Onde há exagero?

Execução gerenciada não comprova que um agente toma decisões de negócio corretas. Hospedagem, rastreamento, avaliação e aplicação de políticas resolvem problemas diferentes. Nenhum deles elimina sua responsabilidade de escolher uma tarefa útil, definir ações aceitáveis e examinar as falhas.

A promessa de “Any framework” também não deve ser entendida como ausência de trabalho de integração. A flexibilidade da plataforma ainda exige validar dependências, autenticação, instrumentação e os contratos de cada serviço adotado.

Por fim, adotar todos os componentes não comprova que a aplicação está pronta para produção. Um assistente de atendimento que só consulta dados não melhora ao ganhar autorização para pagamentos ou um navegador de que não precisa. Acrescente recursos quando uma tarefa concreta os exigir e inclua a ampliação das permissões na revisão.

Por onde começar na segunda-feira?

Escolha uma tarefa de agente que já exista e registre qual responsabilidade operacional está atrasando a entrega. Teste em um piloto apenas os recursos do AgentCore necessários para eliminar esse atraso. Compare a implantação resultante, o tratamento de falhas e o trabalho que fica com sua equipe com o que a stack atual oferece. Amplie a adoção quando as evidências justificarem a mudança.

Receba na newsletter guias práticos para desenvolver e operar sistemas de IA.