Os melhores casos de uso de agentes podem ser os playbooks que seus times já seguem. A AWS mostra na migração

Quando a pergunta é por onde começar com agentes, muitos times procuram problemas abertos, que parecem exigir inteligência. A resposta melhor costuma ser o contrário: trabalho longo, cheio de ferramentas, que as pessoas já executam a partir de um playbook, com etapas, checagens e responsáveis conhecidos. Migração para a nuvem é um caso clássico, e a AWS publicou uma arquitetura para ela em 1º de outubro.

O que a AWS descreve

O post, de Nikhil Jha, Kaushal Agrawal, Tarun Tarun e Vyasamaharshi Garigipati, apresenta quatro agentes no Amazon Bedrock AgentCore, construídos com o Strands Agents SDK:

• Agente de entrada. Lê os insumos da migração em documentos via ferramentas MCP e propõe uma arquitetura de destino.
• Agente de infraestrutura como código. Gera o código de infraestrutura compondo módulos internos aprovados, em vez de escrever a infraestrutura do zero.
• Agente de inteligência e governança da migração. Produz relatórios do portfólio, avaliações e visões de governança sobre as aplicações.
• Agente de SRE. Monitora as cargas depois do cutover e faz remediação automatizada.

A base é o AgentCore: Runtime, Gateway, Memory para estado de sessão e contexto compartilhado entre agentes, Identity para autenticação, Policy aplicando regras Cedar e Observability. O Amazon Bedrock Guardrails bloqueia saídas fora de conformidade. Bancos de dados e servidores migram pelo AWS DMS e pelo AWS Transform. Os autores dizem que ações automatizadas exigem aprovação humana explícita antes da execução.

O post informa que o desenvolvimento de código de infraestrutura caiu de três a quatro semanas por aplicação para minutos, num portfólio de mais de 300 aplicações, segundo o acompanhamento interno do projeto. É um número informado pelos próprios autores, não um benchmark independente.

Por que migração combina com agentes

1. Entrada: ler insumos, propor destino
2. Arquiteto aprova o destino
3. IaC a partir de módulos aprovados
4. Checagens do pipeline e aprovação
5. Cutover com plano de rollback
6. Agente de SRE observa e propõe correções

• Planejar: Entrada: ler insumos, propor destino · Arquiteto aprova o destino
• Construir: IaC a partir de módulos aprovados · Checagens do pipeline e aprovação
• Operar: Cutover com plano de rollback · Agente de SRE observa e propõe correções

Trabalho do agentePortão de aprovação humana

A decomposição já existe. Descoberta, desenho, construção, cutover e operação são fases conhecidas. Cada agente fica com uma fase, o que mantém ferramentas e permissões estreitas. É o primeiro teste do framework para encontrar onde o agente cabe: um processo que já existe, com etapas claras.

A saída pode ser checada. O código de infraestrutura passa pelo mesmo pipeline, pelas mesmas checagens de política e revisões que o código escrito por pessoas. Compor módulos aprovados é uma boa escolha de desenho: o agente monta a partir de peças em que o time de plataforma já confia, e a revisão passa a ser sobre escolhas, não sobre cada linha.

O estado dura muito. Migrações levam semanas. A memória compartilhada entre agentes é o que permite ao agente de governança falar do portfólio inteiro. Também significa que essa memória guarda detalhes de arquitetura e inventários, que merecem o mesmo controle de acesso da CMDB.

A política fica fora dos agentes. Regras Cedar no AgentCore Policy são avaliadas pela plataforma, não pelo modelo. É o lugar certo para “este agente não mexe na rede de produção”, como defendemos na análise sobre contenção de agentes.

O que falta, e o que você precisa acrescentar

Rollback. O post não trata de rollback de forma explícita. Em migração, rollback é o controle que mais importa no dia do cutover. Escreva isso no playbook antes de qualquer agente tocar em etapas de cutover: o que dispara, quem decide e quanto tempo leva.

Gestão de mudanças e comunicação ao regulador. Para instituições financeiras, a Resolução CMN 4.893 exige comunicar ao Banco Central a contratação de serviços relevantes de processamento, armazenamento de dados e computação em nuvem, além de planos de continuidade. Um agente que acelera a migração não muda essas obrigações; ele só faz com que o cronograma regulatório precise andar junto. O código de infraestrutura gerado por agente e as correções propostas por ele precisam dos mesmos tickets, aprovações e evidências que as mudanças feitas por pessoas.

Onde as coisas rodam. Antes de montar o desenho, confira quais componentes do AgentCore estão disponíveis na região de São Paulo e quais rodariam em outra região. A memória compartilhada guarda o inventário do seu ambiente; onde ela fica é uma decisão de custódia.

A autoridade do agente de SRE. Remediação automatizada depois do cutover é onde a autonomia exige mais cuidado. Vale a mesma escada de permissões do DevOps Agent da própria AWS: ler à vontade, propor com generosidade, agir só com concessão explícita.

O que fazer agora

1. Escolha um playbook que seus times já executam (migração, onboarding, aplicação de patches, revisão de acessos), não um problema aberto.
2. Dê a cada agente uma fase, com ferramentas e permissões próprias.
3. Restrinja a geração a blocos aprovados sempre que possível: módulos, templates, runbooks.
4. Coloque aprovação humana nas fronteiras entre fases e registre como evidência.
5. Escreva rollback e condições de parada antes de automatizar qualquer etapa que mude produção.
6. Meça por fase: tempo economizado, retrabalho e defeitos pegos em cada portão.

Em resumo

O desenho da AWS funciona por um motivo que tem pouco a ver com IA: migração já era uma sequência disciplinada e verificável. Os agentes aceleram cada etapa sem mudar quem decide entre elas. Procure esse formato na sua operação antes de procurar problemas que só parecem exigir inteligência.