Agentes de IA que fazem trabalho de verdade: o que é o Amazon Bedrock AgentCore e como ele muda o jogo por setor

Um chatbot responde. Um agente executa. Essa é a diferença que separa "IA que dá uma boa resposta" de "IA que abre o chamado, cruza a nota com o orçamento, consulta o estoque e confirma a reserva". O Amazon Bedrock AgentCore é a camada da AWS para colocar esse segundo tipo de IA para trabalhar em produção, com ferramentas, memória entre sessões, identidade e auditoria. Este texto explica o que ele realmente é e mostra um caso concreto de agente para cada setor da Jornada AWS: construção, saúde, SaaS, varejo e turismo.

Sair de responder para resolver a tarefa até o fim, sozinha, sem alguém copiar o resultado de um lugar para outro, não é uma diferença de grau, é de categoria. Isso tem nome: agente. E, na AWS, tem uma plataforma feita para operá-lo com segurança em produção, o Amazon Bedrock AgentCore, que ficou disponível de forma geral (GA) em outubro de 2025.

Antes de qualquer empolgação, um aviso que repito em todo projeto: isso não é mágica. Um agente que age no seu sistema, sem desenho de permissão, sem revisão humana onde o risco pede e sem observabilidade, é um passivo, não um ativo. A boa notícia é que o AgentCore existe justamente para dar esse desenho e essa governança. A má notícia para quem quer atalho é que a governança continua sendo trabalho seu.

Chatbot responde, agente executa: a diferença que importa

Resposta direta: um chatbot recebe uma pergunta e devolve um texto. Um agente recebe um objetivo, raciocina em passos, escolhe e usa ferramentas (consultar um sistema, abrir um chamado, atualizar um registro), guarda o que aprendeu entre conversas e age com uma identidade que define o que ele pode ou não fazer.

Fica mais claro com um exemplo. Pergunte a um chatbot "onde está meu pedido?" e, no melhor caso, ele explica como você mesmo consulta o rastreio. Peça a um agente e ele consulta o pedido no seu sistema de logística, lê o status real, responde com a previsão de entrega e, se você pedir a troca, abre a troca. O primeiro informa. O segundo faz.

Três capacidades separam um do outro:

• Ferramentas (tools): o agente chama sistemas de verdade. Uma API do seu ERP, uma função que consulta o estoque, um leitor de documento. Sem ferramenta, ele só conversa.
• Memória entre sessões: o agente lembra do cliente, do histórico da obra, do padrão de um fornecedor, de uma conversa para a outra. Sem memória, cada atendimento começa do zero.
• Identidade e permissão: o agente age com credencial própria e escopo definido, então você controla exatamente o que ele pode tocar. Sem isso, você tem um estagiário com a chave-mestra da empresa.

O Amazon Bedrock já resolvia a parte de "conversar bem" (tratei do padrão RAG no post sobre IA generativa na AWS). O AgentCore resolve a parte de "agir com segurança". Vale a distinção: houve um serviço anterior, o Amazon Bedrock Agents, que era uma camada de orquestração. O AgentCore é a evolução disso para uma plataforma completa de ciclo de vida do agente em produção, e trabalha com qualquer framework aberto (Strands Agents, LangGraph, CrewAI, LlamaIndex) e qualquer modelo, dentro ou fora da AWS, conforme a documentação oficial.

Os blocos do AgentCore, em linguagem de negócio

Não vou transformar isto em documentação. Mas para você entender os casos adiante, precisa reconhecer as peças. São serviços modulares que funcionam juntos ou separados, todos descritos na documentação da AWS:

• Runtime: onde o agente roda. É um ambiente serverless (você não gerencia servidor) que isola cada sessão de usuário em seu próprio espaço, para que a conversa de um cliente nunca vaze para a de outro. Pense no runtime como o "chão de fábrica" seguro do agente.
• Memory (memória): o que o agente lembra. Memória de curto prazo para a conversa em andamento e memória de longo prazo que persiste entre sessões. É o que faz o agente reconhecer o cliente recorrente e o histórico de um caso.
• Gateway: o conector. Transforma suas APIs, funções AWS Lambda e sistemas existentes em ferramentas que o agente sabe usar, no padrão aberto MCP (Model Context Protocol), com integrações prontas para plataformas como Salesforce, Slack e JIRA. É a peça que tira o agente do texto e o coloca dentro dos seus sistemas.
• Identity (identidade): quem o agente é e o que pode fazer. Gerencia a identidade e o acesso do agente, compatível com provedores que você já usa, como Amazon Cognito, Okta e Microsoft Entra ID. É onde mora o princípio de permissão mínima.
• Observability (observabilidade): o que o agente fez. Rastreia cada passo do raciocínio e cada chamada de ferramenta, em formato padrão OpenTelemetry, para você auditar, depurar e provar o que aconteceu. Sem isso, um agente é uma caixa-preta, e caixa-preta não passa em auditoria.

Além desses, o AgentCore traz duas ferramentas nativas que aparecem muito nos casos reais: o Browser Tool, um navegador na nuvem que deixa o agente operar sistemas web (preencher formulário, navegar, extrair informação) mesmo quando o sistema legado não tem API, e o Code Interpreter, um ambiente isolado onde o agente executa código para fazer cálculo e análise com precisão. Para quem quer travar o comportamento por regra, há ainda o AgentCore Policy, que define, com linguagem de política, o que o agente pode chamar e sob quais condições, interceptando cada uso de ferramenta antes de executar.

Guarde esses nomes. A partir daqui, cada caso vai mostrar quais peças entram e por quê.

Um agente concreto para cada setor da Jornada

Este é o coração do texto. Para cada setor forte no Nordeste, um agente que faz trabalho de verdade: o problema, o que ele executa passo a passo, com quais peças do AgentCore, onde entra o freio humano e qual o ganho. São padrões viáveis hoje, não promessa de futuro. Olhei por tarefa no post de IA aplicada na PME e por KPI no post de soluções por setor; aqui a lente é a ação autônoma.

Construção e incorporação: o agente que vigia o desvio de orçamento

O problema. A medição de obra chega em papel ou foto de WhatsApp, o financeiro consolida no fim do mês, e o diretor descobre o estouro de orçamento quando já não dá para corrigir. Cada semana de atraso nessa consolidação é caixa decidido no escuro.

O que o agente faz. Ele recebe a medição e a nota do fornecedor, usa uma ferramenta de leitura de documento (conectada via Gateway) para extrair os campos, e consulta o orçamento e o previsto da etapa no ERP, também via Gateway, que transformou a API do sistema numa ferramenta que ele sabe chamar. Cruza previsto contra realizado por obra e por etapa. A Memory guarda o histórico de cada empreendimento e o padrão de cada fornecedor entre uma medição e outra, então o agente reconhece quando um item fugiu da curva. Quando o desvio passa de um limite que você definiu, ele registra a pendência e dispara o alerta para o engenheiro responsável. É o mesmo princípio de um agente que acompanha o diário de obra e sinaliza a divergência assim que ela aparece.

O freio humano. O agente alerta e sugere. O aceite da medição e a liberação de pagamento continuam com o engenheiro e o financeiro. Ninguém automatiza a assinatura do cheque.

O ganho. O desvio aparece na semana em que acontece, não no fechamento. A diretoria decide com a obra ainda em andamento.

Saúde (clínicas e laboratórios): o agente que ataca a glosa na raiz

O problema. O convênio glosa parte do faturamento por divergência de guia, e reconciliar o que foi autorizado com o que foi faturado é trabalho manual, lento e recorrente. Some a isso a fila de pré-atendimento, com paciente pedindo agendamento e informação a qualquer hora.

O que o agente faz. Na conciliação, ele lê a guia e a autorização, consulta o faturamento no sistema de gestão via Gateway, e cruza item a item o que foi autorizado contra o que foi cobrado. Identifica a divergência que gera glosa e monta a base do recurso. A Memory aprende os motivos recorrentes de glosa por operadora, então o agente melhora a triagem com o tempo. Num agente de pré-atendimento, ele coleta os dados iniciais, checa a agenda por especialidade via Gateway e sugere o horário, sempre encaminhando para a equipe.

O freio humano. Aqui ele é forte e inegociável. Dado de saúde é dado pessoal sensível sob a LGPD: exige base legal correta, criptografia, acesso mínimo (o Identity garante que o agente só enxergue o necessário) e retenção definida antes de ligar qualquer coisa. O agente não dá diagnóstico e não decide conduta clínica. O recurso de glosa só sai depois de revisão humana. Isto é human-in-the-loop no sentido literal, com registro de tudo na Observability para auditoria.

O ganho. A glosa é atacada na origem, de forma consistente, e a equipe deixa de gastar horas cruzando papel para gastá-las nos casos que realmente precisam de gente. Tratei do desenho de LGPD para saúde na nuvem no post sobre LGPD na cloud.

SaaS e startups: o agente de suporte N1 que resolve o ticket

O problema. O suporte de nível 1 se afoga em pedidos repetidos (reenviar convite, ajustar uma configuração, explicar um erro conhecido), e o cliente espera enquanto a fila cresce. O chatbot de FAQ ameniza, mas não resolve: ele responde e devolve o problema para o humano.

O que o agente faz. Ele consulta a documentação e a base de conhecimento para entender o pedido, verifica o estado real da conta do cliente no seu sistema via Gateway (a API interna virou ferramenta) e, quando é algo dentro da alçada de um N1, executa: reenvia o convite, corrige a configuração, aplica o ajuste permitido pela regra. Quando o caso extrapola, ele abre ou atualiza o chamado no seu sistema de tickets, também via Gateway, já com todo o contexto anexado, para o N2 não recomeçar do zero. A Memory mantém o histórico do cliente entre conversas, e o Identity garante que o agente aja com a permissão exata de um N1, nada além.

O freio humano. Ações destrutivas, reembolso, mudança de plano acima de um limite ou qualquer coisa fora da alçada escalam automaticamente para uma pessoa. O escopo do que o agente pode executar é definido por política, não por confiança.

O ganho. O ticket de baixo risco é resolvido de ponta a ponta, e o time humano fica com o que exige julgamento. É a diferença entre "abrimos seu chamado" e "já resolvi, pode conferir". O agente de onboarding segue a mesma lógica: guia o novo cliente e executa os passos de configuração em vez de só listá-los.

Varejo e e-commerce: o agente que conclui a ação no WhatsApp

O problema. O WhatsApp vira um balcão de FAQ. O cliente quer rastrear o pedido, trocar um produto ou saber se tem no estoque, e o atendente humano vira ponte manual entre a conversa e três sistemas diferentes. Fora do horário, a venda ou a retenção escapa.

O que o agente faz. No rastreio, ele consulta o pedido no ERP e na transportadora via Gateway e devolve o status real, não um link genérico. Numa troca, verifica a política, checa o estoque do item substituto, e abre a troca no sistema, gerando o próximo passo (etiqueta, protocolo). Numa dúvida de disponibilidade, consulta o estoque na hora. A Memory guarda o histórico do cliente e o fio da conversa, então ele não pede duas vezes o número do pedido. Quando o sistema legado da loja não tem API, o Browser Tool permite que o agente opere a tela como um humano operaria.

O freio humano. Reembolso acima de um valor, exceção de política ou reclamação sensível vão para um atendente, com todo o histórico em mãos. O agente conclui o rotineiro e entrega o excepcional já contextualizado.

O ganho. O cliente resolve no mesmo canal, na hora, inclusive de madrugada. O atendimento deixa de ser "informar" e passa a ser "concluir".

Serviços e turismo: o agente de reservas que confirma na hora

O problema. Pousada, hotel e agência perdem reserva por resposta lenta. O contato chega, ninguém responde a tempo a disponibilidade e o preço, e o hóspede fecha com o concorrente que respondeu primeiro. Na alta temporada, o volume de mensagem engole a equipe.

O que o agente faz. Ele consulta a disponibilidade real no motor de reservas ou no PMS via Gateway, responde preço e datas com base no que existe de fato, segura a reserva e confirma. Para preferências de hóspede recorrente (andar alto, check-in tardio), a Memory lembra de uma estadia para a outra. Se o sistema de reservas for uma tela web sem integração, o Browser Tool deixa o agente operá-lo. No que vejo nos projetos da RFX, turismo é onde a velocidade de resposta mais vira dinheiro: a reserva vai para quem respondeu primeiro, e um agente responde sempre.

O freio humano. Overbooking, tarifa especial, grupo grande ou pedido fora do padrão escalam para o gerente. O agente cuida do fluxo comum e passa o complexo para a pessoa certa.

O ganho. A janela de resposta cai para o tempo de uma mensagem, a qualquer hora, e a reserva rotineira se fecha sozinha.

Governança e custo: o que separa um agente útil de um risco

Um agente que age sozinho amplia tudo, inclusive o erro. Por isso governança não é etapa posterior, é parte do desenho. No que vemos nos projetos da RFX, quatro controles não são negociáveis:

Identidade e permissão mínima. O agente age com credencial própria e o menor escopo possível. Ele não deve poder tocar em nada além do que a tarefa exige. O Identity do AgentCore existe para isso, e o Policy permite travar, por regra, quais ferramentas o agente chama e sob quais condições, interceptando cada chamada antes de executar. A pergunta certa nunca é "o que o agente consegue fazer?", e sim "o que o agente pode fazer?".

Human-in-the-loop onde o risco pede. Ação irreversível, dado sensível, dinheiro e decisão que afeta pessoa passam por revisão humana. O agente propõe e executa o rotineiro; a pessoa aprova o que tem peso. O truque é calibrar: freio de mais mata o ganho, freio de menos vira incidente.

Observabilidade e auditoria. Cada passo do agente e cada chamada de ferramenta ficam rastreados, no padrão OpenTelemetry que a Observability emite. Isso não é luxo de engenharia: é o que permite responder "por que o agente fez isso?" quando alguém perguntar, e é pré-requisito para qualquer processo auditável.

Controle de custo. Um agente que raciocina em vários passos e chama várias ferramentas consome mais que um chatbot de uma resposta só. O AgentCore tem cobrança por consumo, sem compromisso mínimo, o que é bom para começar pequeno, mas exige disciplina: limite de gasto, alarme de anomalia e teto por sessão precisam entrar no desenho, não depois do susto. Custo é uma decisão de arquitetura, tanto quanto latência ou segurança, e é o mesmo princípio de FinOps que aplico em qualquer projeto de nuvem. Um agente sem budget definido é um cano aberto.

Sobre LGPD, a régua é a de sempre, só que mais afiada, porque o agente age. Onde ele toca dado pessoal, valem base legal, minimização, acesso restrito e retenção. E o risco maior que vejo não é a plataforma da AWS, é o "shadow AI": gente do time plugando um agente numa ferramenta pública, sem governança, com acesso a sistema real. Tratei desse ponto em detalhe no post sobre shadow AI e governança, leitura que recomendo antes de liberar qualquer agente para a operação.

Como começar sem se enrolar

Resposta direta: escolha um caso de baixo risco e alto volume, coloque human-in-the-loop desde o primeiro dia, rode um piloto pequeno e meça antes de expandir. Não comece pelo processo mais crítico da empresa.

A ordem que sugiro em todo projeto:

1. Escolha um caso onde o erro é barato. Rastreio de pedido, resposta de disponibilidade, triagem de glosa com revisão humana. Fuja do processo que, se falhar, para a operação.
2. Desenhe o freio antes da ferramenta. Defina o que o agente pode executar sozinho e o que precisa de aprovação, e escope a permissão para o mínimo. Governança primeiro, automação depois.
3. Rode um piloto com volume real e escopo limitado. Defina o que é sucesso antes de ligar, e deixe a observabilidade registrando tudo desde o começo.
4. Meça e expanda com prova. Com o agente auditável e o custo conhecido, avance para o próximo caso.

Quem tenta automatizar o processo mais sensível de cara erra o escopo, assusta o time e trava. Quem começa num caso onde o agente pode falhar sem estrago cria confiança e avança. É o mesmo padrão que vale para qualquer adoção de IA, agora com uma exigência a mais de desenho.

Se você quer ver isso funcionando com a mão na massa, é exatamente o que fazemos no Activation Day: os laboratórios práticos incluem o Amazon Bedrock AgentCore, para você montar um agente de verdade e sentir onde entra cada peça. E se prefere primeiro entender qual caso faz sentido para o seu negócio, dia 15 de julho acontece a segunda edição da Jornada AWS em João Pessoa, onde donos de negócio da região discutem, ao vivo, o que agente resolve e o que ainda pede gente. Agentes de IA é o assunto que mais aparece nas perguntas dos inscritos deste ano.

Colocar um agente para trabalhar não é apertar um botão, é um projeto de escopo, permissão e medição. É esse recorte que fazemos na consultoria cloud da RFX: escolher o primeiro caso, desenhar a governança e garantir que custo e LGPD estão sob controle desde o começo. Se este texto fez sentido, o próximo passo é um diagnóstico do seu primeiro caso de agente.

Perguntas frequentes

Qual a diferença entre um chatbot e um agente de IA?

Um chatbot responde perguntas com texto. Um agente recebe um objetivo, raciocina em passos e executa a tarefa usando ferramentas (consultar um sistema, abrir um chamado, atualizar um registro), com memória entre sessões e uma identidade que define o que ele pode fazer. Na prática, o chatbot informa "como você rastreia seu pedido"; o agente consulta o pedido, responde o status e, se você pedir, abre a troca.

O que é o Amazon Bedrock AgentCore?

É a plataforma da AWS para construir, implantar e operar agentes de IA em produção com segurança, disponível de forma geral desde outubro de 2025. Ela reúne serviços modulares (Runtime para rodar o agente, Memory para memória, Gateway para conectar sistemas, Identity para permissão e Observability para auditoria) mais ferramentas nativas como Browser e Code Interpreter. Funciona com qualquer framework aberto (Strands, LangGraph, CrewAI, LlamaIndex) e qualquer modelo, conforme a documentação oficial da AWS.

AgentCore é o mesmo que Amazon Bedrock Agents?

Não. O Amazon Bedrock Agents era uma camada de orquestração para montar um agente. O AgentCore é a evolução para uma plataforma completa que cobre o ciclo de vida do agente em produção: execução isolada, memória, conexão com sistemas, identidade, política e observabilidade. Você pode usar os serviços do AgentCore juntos ou separados, e com o framework que já usa.

Um agente de IA é seguro para tocar em dado de cliente sob a LGPD?

Pode ser, se desenhado com método. A chave é permissão mínima (o agente só enxerga o necessário), human-in-the-loop onde o dado é sensível, criptografia, retenção definida e registro de tudo para auditoria. Para dado pessoal sensível, como o de saúde, isso é pré-requisito, não opcional. O risco maior costuma não ser a plataforma da AWS, e sim o uso de ferramentas públicas sem governança, o chamado shadow AI.

Quanto custa rodar um agente de IA no AgentCore?

A cobrança é por consumo, sem compromisso mínimo, conforme a página oficial de preços da AWS. Um agente que raciocina em vários passos e chama várias ferramentas consome mais que um chatbot simples, então limite de gasto, alarme de anomalia e teto por sessão precisam entrar no desenho desde o início. Como os serviços são cotados em dólar e sua receita é em real, o câmbio afeta o valor final. Simule o seu cenário antes de escalar.

Por onde devo começar com agentes de IA?

Por um caso de baixo risco e alto volume, com revisão humana desde o primeiro dia. Rastreio de pedido, resposta de disponibilidade ou triagem com aprovação humana são bons pontos de entrada, porque o erro é barato e o ganho é visível. Rode um piloto pequeno com escopo limitado, meça, e só então avance para casos mais críticos. Governança primeiro, automação depois.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções AWS na RFX Tecnologia

Arquiteto de soluções AWS na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.