A AWS Professional Services apresentou, em 1º de outubro de 2026, um padrão de arquitetura com quatro agentes de inteligência artificial construídos sobre o Amazon Bedrock AgentCore para conduzir migrações de nuvem corporativas de ponta a ponta. O material foi publicado no blog de machine learning da própria AWS, com revisão e atualização em outubro de 2026, e descreve como um programa empresarial com mais de 300 aplicações e prazo fixado para o fim do ano fiscal respondeu a uma pergunta prática: quais etapas de uma grande migração cabem em um serviço gerenciado e quais dependem de automação sob medida.
Um padrão de quatro agentes para duas jornadas
O framework organiza o trabalho em duas jornadas — migração e operações, e em quatro agentes especializados, construídos com o Strands Agents SDK. O Intake Agent, na fase 1, lê documentos de arquitetura, questionários e registros de dependências por meio de ferramentas MCP e define a arquitetura do estado-alvo.
O IaC Agent, na fase 2, gera infraestrutura como código compondo os módulos internos aprovados pela organização. O Migration Intelligence and Governance Agent produz relatórios e governança dentro das ferramentas do próprio programa, e o agente de Site Reliability Engineering (SRE) assume as operações depois do cutover.
Cada agente alcança suas origens e destinos por meio de ferramentas de Model Context Protocol (MCP) expostas pelo AgentCore Gateway. A arquitetura se conecta ao programa de migração em três pontos, os sistemas que guardam as entradas, a composição de IaC e as operações após o cutover, e aplica controles de segurança em cada um deles.
Serviço gerenciado, agentes sob medida e mcp
O texto deixa claro que o padrão roda ao lado do AWS Transform, não no lugar dele: o serviço gerenciado cobre migração e modernização de cargas de servidores, redes, mainframe,.NET e código de aplicação, enquanto o AWS Database Migration Service (AWS DMS) atende a camada de banco de dados. Os agentes personalizados entram onde o programa mantém exigências próprias.
Na experiência relatada, três condições apareceram juntas. Primeiro, origens e destinos conectados por MCP: uma wiki interna com padrões de segurança, um sistema de tickets, uma plataforma de colaboração e uma API de provisionamento desenvolvida internamente.
Segundo, composição de IaC específica da organização, obrigada a usar uma biblioteca de módulos revisada e aprovada pelo escritório de segurança, trabalho que, feito à mão, consumia de 3 a 4 semanas por aplicação. Terceiro, escopo que continuava depois da entrega, com operações fora do alcance dos serviços de migração.
Por que isso importa
O número central do relato é a compressão do tempo de desenvolvimento de infraestrutura como código: de 3 a 4 semanas por aplicação para minutos, segundo os dados internos de acompanhamento do projeto. Em um portfólio de mais de 300 aplicações, a conta original equivalia a anos de esforço de engenharia, e é justamente esse volume que costuma definir se um programa cumpre ou não o prazo do ano fiscal.
Ainda assim, a adoção não é trivial. O material exige uma conta AWS com acesso ao Amazon Bedrock AgentCore e a modelos de fundação do Amazon Bedrock, além de familiaridade com o Strands Agents SDK, com padrões de servidor MCP e com o ferramental de IaC da própria organização.
A recomendação explícita é verificar antes se um serviço gerenciado da AWS já cobre o caminho de migração em questão, só depois faz sentido escrever agentes próprios.
Para equipes que tocam migrações de grande porte, o desenho sugere um critério útil: separar o que é commodity, servidores, bancos, código legado, do que é regra interna, como bibliotecas de módulos aprovadas, sistemas de tickets e APIs próprias, e reservar os agentes para essa segunda camada.
Fontes e links
- AWS (blog de machine learning da AWS), matéria original
- Amazon Bedrock AgentCore
- AWS Transform
- AWS Database Migration Service (AWS DMS)
- Strands Agents SDK
