AWS: agentes de IA em campo com Bedrock, AgentCore e Nova
TL;DR
O movimento mais importante aqui não é só “ter agentes”, mas separar claramente o que o modelo faz, o que a infraestrutura controla e o que pode ou não executar. No stack da AWS, o Amazon Bedrock cobre a base de agentes e o Amazon Bedrock AgentCore adiciona runtime, gateway, memória, identidade, observabilidade e políticas para operar isso em produção.
Na prática, isso importa porque agentes autônomos deixam de ser apenas um loop de prompt + ferramenta e passam a ter isolamento de sessão, autorização determinística e controles de segurança na borda. Para times que precisam colocar IA em produção com governança, especialmente em ambientes regulados no Brasil, essa separação reduz improviso e melhora a previsibilidade operacional.
O que mudou no stack da AWS para agentes
Durante um bom tempo, construir agente na nuvem era sinônimo de costurar componentes: modelo, memória, ferramentas, retries, logs, autorização e execução. A AWS passou a organizar isso em camadas mais explícitas: o Amazon Bedrock Agents oferece a base de orquestração, enquanto o Amazon Bedrock AgentCore foca na operação de agentes customizados em escala.
Esse desenho faz diferença porque o agente deixa de depender só de “obedecer ao prompt”. Em vez disso, a execução ganha pontos de controle fora do modelo, o que é mais apropriado quando a tarefa envolve passo a passo longo, acesso a sistemas internos e regras de negócio que não podem ficar implícitas.
Bedrock como camada de agentes
O Bedrock é a porta de entrada para construir experiências agentic com modelos, ferramentas e integrações. A documentação oficial da AWS também mostra o uso do Amazon Nova como foundation model em agentes, conectando o modelo ao fluxo de execução via Bedrock Agents.
Isso é útil quando você quer manter o raciocínio do agente próximo à infraestrutura gerenciada da AWS, sem precisar reinventar a parte de plumbing. O ganho não é só conveniência: é reduzir a quantidade de cola entre o prompt, o tool calling e o ambiente onde a execução acontece.
AgentCore como camada de produção
O AgentCore se posiciona como infraestrutura para agentes em produção: runtime, gateway, memória, identidade, observabilidade e avaliações. O ponto central é que você pode construir com frameworks diferentes e ainda assim empacotar a execução em uma camada operacional mais uniforme.
Na prática, isso ajuda quando um time já tem seu próprio framework de agente, mas não quer abrir mão de controles de produção. Em vez de amarrar tudo ao modelo ou ao framework, o foco passa a ser o contrato de execução.
AgentCore Runtime: isolamento por sessão
Uma das partes mais relevantes para agentes “em campo” é o runtime com sessões isoladas. A documentação descreve execução em microVM dedicada por sessão, com isolamento de compute, memória e filesystem, além de sanitização ao final do ciclo.
Esse detalhe parece infra, mas muda o comportamento arquitetural. Em workflows longos, o agente pode continuar o mesmo atendimento, a mesma análise ou a mesma automação sem misturar contexto entre sessões diferentes; isso é especialmente relevante quando há múltiplos usuários, múltiplas tarefas e risco de contaminação de estado.
Por que isso interessa em workflows long-running
Em automações complexas, o agente raramente conclui tudo em uma única chamada. Ele consulta dados, avalia resposta, aciona ferramenta, volta, reavalia e segue. O runtime com sessão preservada permite manter afinidade de execução com mais segurança do que um fluxo solto em componentes genéricos.
Esse padrão combina bem com casos como triagem de atendimento, automação de operações ou assistentes internos que precisam “lembrar” o estado de uma mesma tarefa por horas, não por segundos.
Gateway e Policy: autorização fora do prompt
Outro avanço importante é a camada de Policy no AgentCore usando Cedar. Em vez de confiar apenas em instruções textuais para limitar ações, a arquitetura aplica autorização determinística sobre chamadas de tools e workflows.
Essa mudança é relevante porque o modelo pode errar, ser induzido por prompt injection ou simplesmente escolher uma ação indevida em um contexto ambíguo. Quando a decisão de permitir ou bloquear uma execução fica no gateway, a política deixa de ser um desejo e passa a ser uma verificação real.
Guardrails na borda da execução
A AWS também documenta a integração de Guardrails com Policy no AgentCore, aplicando checagens sobre entradas e saídas antes que chamadas sigam para sistemas downstream. Isso ajuda a mitigar exposição de dados sensíveis e a conter instruções maliciosas no perímetro.
Para equipes que lidam com dados internos, isso é especialmente prático. O problema não é só “o modelo falou algo indevido”; é o modelo tentar acionar uma integração com conteúdo inadequado, e a plataforma ter meios não ambíguos de barrar isso.
Amazon Nova como motor para tarefas agentic
A família Amazon Nova entra como base model para essas experiências, e a AWS mostra em documentação como usá-la em agentes via Bedrock. O papel aqui é fornecer raciocínio e execução de tarefas com suporte a fluxos que dependem de chamadas a ferramentas e serviços.
Na prática, Nova faz sentido quando o agente precisa navegar por instruções, seguir passos e manter coerência ao longo da tarefa. Para automações de atendimento, busca interna, assistentes operacionais e workflows guiados, o foco não é só gerar texto, mas sustentar decisões de forma consistente ao longo do processo.
Agentes com Nova e Bedrock
A documentação oficial da AWS descreve o uso de Nova como foundation model em agentes integrados ao Bedrock. Isso permite que o time escolha o modelo e continue usando a camada de agente da AWS para orquestração e integração com ferramentas.
Esse acoplamento é útil para separar escolha de modelo de escolha de infraestrutura. Assim, dá para comparar comportamento, custo e latência do modelo sem reescrever toda a arquitetura de execução.
Como isso se traduz em arquitetura real
Se você olhar para um agente autônomo de ponta a ponta, a divisão de responsabilidades fica mais clara. O modelo interpreta intenção e planeja passos; o AgentCore protege a execução; o gateway controla chamadas; o runtime isola sessões; e as policies definem o que pode acontecer.
Esse arranjo é valioso porque transforma o agente em um sistema observável e governável, não apenas em uma sequência de prompts. Em produção, isso costuma ser a diferença entre um protótipo que impressiona e uma automação que aguenta semana útil inteira.
Exemplo de desenho mental
Imagine um agente de suporte interno que consulta base de conhecimento, abre ticket, verifica status e aciona uma API de terceiro. Em vez de deixar tudo à mercê do texto gerado, você protege a parte de autorização, registra a sessão e isola a execução por tarefa.
Esse tipo de desenho reduz o custo de auditoria e facilita explicar para engenharia, segurança e negócio o que o agente pode ou não fazer. Em empresas brasileiras que já trabalham com esteira de aprovação, LGPD e controles internos mais rígidos, essa separação conversa melhor com o dia a dia real do que uma automação “solta”.
Por que importa pro dev brasileiro
No Brasil, o impacto aparece em pelo menos três frentes concretas. Primeiro, a LGPD exige cuidado com dados pessoais, o que torna útil ter camadas de autorização e filtragem na infraestrutura em vez de confiar só em prompt. Segundo, muita operação ainda roda em cloud com orçamento apertado e pressão por previsibilidade, então isolamento de sessão e governança ajudam a evitar retrabalho e incidentes caros. Terceiro, times brasileiros frequentemente absorvem IA em projetos de transformação digital sem uma equipe dedicada só a MLOps, o que aumenta o valor de serviços gerenciados.
Também existe a realidade de latência e integração com sistemas legados em empresas como bancos, varejo e serviços públicos. Um agente que consulta dados internos, toma decisão e abre ação precisa lidar com controle e rastreabilidade; nesse cenário, a combinação de runtime isolado, policy e guardrails é mais alinhada ao contexto brasileiro do que uma abordagem puramente experimental.
Como avaliar se o stack faz sentido no seu projeto
Antes de adoção, vale fazer três perguntas simples. A primeira é se o agente precisa executar por muito tempo e manter contexto entre passos; se sim, o runtime com sessão faz diferença. A segunda é se o agente vai tocar sistemas com impacto real; se tocar, policy e guardrails deixam de ser opcionais. A terceira é se o time precisa trocar o modelo com frequência; se sim, uma camada de produção desacoplada do modelo reduz dependência.
Se o seu caso é só um chat interno com uma ou duas chamadas de ferramenta, talvez o stack completo seja mais do que você precisa. Mas se a meta é automation de verdade — com workflow, permissões, rastreio e segurança — aí o desenho da AWS passa a fazer mais sentido.
Conclusão
O avanço mais relevante do ecossistema AWS para agentes não é apenas “modelo novo”, e sim a combinação de modelo, runtime isolado, gateway, policy e guardrails em uma arquitetura que tenta sair do improviso. Amazon Bedrock, AgentCore e Nova apontam para um cenário em que agentes autônomos podem operar com mais previsibilidade, especialmente quando há integração com sistemas reais e exigência de controle.
Se você quer tirar isso do discurso e ir para prática em menos de 1 hora, abra a documentação oficial do Amazon Bedrock AgentCore, compare com a página de Bedrock Agents e desenhe no papel o fluxo do seu caso de uso: o que o modelo decide, o que a policy bloqueia e onde a sessão precisa ser preservada.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática sobre Amazon Bedrock, Amazon Nova e AgentCore para construir soluções com agentes autônomos.
- Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta para reforçar os fundamentos de IA generativa na AWS e aplicar Bedrock em projetos reais.
- Bootcamp Bradesco Agentes — formação focada em agentes e automação com uma abordagem prática de construção.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
