AWS e OpenAI tratam o agente de IA como carga de trabalho, não como chatbot

Boa parte dos projetos de agentes em empresas gasta os primeiros meses reconstruindo a mesma infraestrutura: um jeito de guardar estado entre etapas, uma identidade de serviço, um modelo de permissões para as ferramentas, uma etapa de aprovação e logs que o time de segurança aceite. Em 29 de setembro, a AWS colocou boa parte disso dentro de um serviço gerenciado.

O Amazon Bedrock Managed Agents, powered by OpenAI, entrou em preview. Segundo a AWS, ele foi desenvolvido em conjunto com a OpenAI e roda sobre uma versão customizada da Agents API da OpenAI, adaptada para funcionar dentro da AWS e se integrar aos recursos da nuvem.

O ponto importante não é existir mais um serviço de agentes. É quais responsabilidades o runtime passa a assumir.

O que foi anunciado

De acordo com a AWS, o serviço gerencia como o modelo guarda estado, escolhe e usa ferramentas, executa código e coordena trabalho em várias etapas. Em detalhe:

• Sessões duráveis guardam mensagens, chamadas de ferramentas e resultados intermediários, para retomar o trabalho depois.
• Skills reutilizáveis empacotam procedimentos especializados, e os agentes se conectam a ferramentas, inclusive servidores MCP.
• Cada agente opera com a sua própria IAM role.
• Há suporte a aprovação humana antes de ações relevantes.
• A atividade de API suportada é registrada no AWS CloudTrail.

Durante o preview não há cobrança adicional além dos recursos consumidos, e a AWS avisa que o preço pode mudar na disponibilidade geral.

Ainda não disponível no Brasil

O preview roda apenas em US East (N. Virginia), US West (Oregon) e US East (Ohio). A região de São Paulo não está na lista do anúncio.

Para empresas brasileiras, isso tem duas consequências práticas. A primeira: testes com dados reais de clientes brasileiros nessas regiões envolvem transferência internacional de dados, que a LGPD trata com regras próprias. Vale envolver o jurídico e o time de privacidade antes, e não depois. A segunda: mesmo sem o serviço aqui, o desenho que ele propõe já serve de referência para quem está construindo agentes hoje, na AWS ou em qualquer outra plataforma.

A mudança: agente como carga de trabalho governada

Nos últimos dois anos, a maioria dos agentes corporativos foi tratada como funcionalidade de aplicação: uma interface de chat com algumas ferramentas por trás, rodando com as credenciais que o app tivesse. Esse modelo não passa em uma revisão de segurança séria.

O Bedrock Managed Agents descreve outro modelo. O agente tem identidade própria, permissões próprias, um estado persistente que pertence a ele, um acesso controlado a ferramentas e uma trilha de auditoria no mesmo lugar em que o resto da AWS é auditado. É assim que as empresas já tratam um microsserviço ou uma rotina agendada.

O padrão não é exclusivo da AWS. No mesmo mês, a Microsoft descreveu o Autopilot como um agente que vive no tenant com identidade própria, e o Google passou a oferecer permissões IAM por app e por data store no Gemini Enterprise. Reunimos essa convergência no nosso guia do stack de 2026.

1. Solicitação
2. Agente com IAM role própria
3. Sessão durável
4. Ferramentas e servidores MCP
5. Aprovação humana para ações relevantes
6. Registro no CloudTrail

Mecanismo oferecido pelo runtime gerenciado (preview)

Acesso ao modelo não é arquitetura de produção

É comum a conversa sobre IA em empresas brasileiras começar por “qual modelo vamos usar”. O anúncio da AWS mostra onde está o trabalho de verdade. Mesmo com um runtime gerenciado, continuam com o seu time:

O escopo de cada agente. Uma IAM role dedicada só ajuda se for restrita. Alguém precisa decidir o que cada agente pode ler e alterar, e revisar isso conforme ele cresce.

O que é uma ação “relevante”. A aprovação humana existe, mas o runtime não sabe quais das suas ações precisam dela. Estornos acima de certo valor? E-mails para clientes? Alterações em cadastro mestre? Essa lista é uma decisão de negócio e precisa estar escrita.

O que fica guardado na sessão. As sessões duráveis retêm mensagens, chamadas e resultados intermediários. Isso ajuda na continuidade e também transforma o armazenamento das sessões em um lugar onde dados pessoais podem se acumular. Classificação, retenção e acesso a esse armazenamento precisam de um responsável.

Quais ferramentas são confiáveis. O MCP facilita conectar agentes a mais sistemas. Cada servidor MCP também passa a fazer parte da sua cadeia de fornecimento, com permissões e falhas próprias.

A avaliação. Nada no anúncio diz se o agente faz bem o trabalho. Continuam sendo necessários casos de teste, critérios de aceite e uma forma de repeti-los quando o modelo ou o prompt mudam.

O que fazer agora

1. Se a sua empresa é AWS, teste em uma conta sandbox nas regiões do preview, com dados sintéticos ou não sensíveis.
2. Desenhe o modelo de identidade antes de conectar ferramentas, seja qual for a plataforma: um papel por agente, limites de permissão e revisão periódica.
3. Escreva a política de aprovação para as ações relevantes.
4. Acompanhe a disponibilidade regional. Quando o serviço chegar a São Paulo, a conversa sobre dados muda.

Em resumo

O Bedrock Managed Agents indica que o runtime de agentes está virando infraestrutura, com identidade, estado e auditoria embutidos. Isso elimina uma quantidade real de engenharia repetitiva. E deixa mais claras as perguntas difíceis: quais permissões, quais aprovações, quais evidências e quem responde pelo agente depois que ele entra em produção.