# AWS describes four agents for a migration program spanning over 300 applications

- Source: MechNext — https://mechnext.eu/en/article/27-aws-describes-four-agents-for-a-migration-program-spanning-over-300-applications
- Published: 2026-10-02
- Updated: 2026-10-02
- Category: Industry News
- Language: en (Markdown in other languages: ?lang=de, ?lang=sk, ?lang=pl, ?lang=zh, ?lang=ru)

> An AWS blog post connects agents for architecture intake, infrastructure code, migration governance and operations after cutover. Its reported reduction in IaC development time comes from internal tracking for the specific implementation.

An AWS Machine Learning Blog post titled “Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore” describes a migration program covering more than 300 applications. It sets out four roles in that program: the Intake Agent, IaC Agent, Migration Intelligence and Governance Agent, and SRE Agent. The account describes a particular implementation by AWS, including how information moves between the agents and where approval is required.

### Turning application records into a target architecture

The Intake Agent reads architecture documents, questionnaires and dependency records through MCP tools, according to the post. It uses those inputs to produce a target AWS architecture. That sequence matters because the target architecture is tied to material about the application and its dependencies. Across a program of more than 300 applications, the post presents this as a repeatable intake step for turning varied records into an architecture for each application.

The output also feeds the next role. In the described implementation, AgentCore memory holds shared context so the IaC Agent can read the Intake Agent’s target architecture and dependency mappings. The shared context explains the handoff between understanding an application and preparing infrastructure code for it. It also makes the agents’ responsibilities easier to distinguish: one assembles and interprets the inputs, while the other uses the resulting architecture and mappings in its own work.

### Generating infrastructure code within defined rules

AWS says the IaC Agent generates infrastructure code using approved internal modules and organizational patterns. In this account, generation is connected to both the Intake Agent’s output and the patterns selected for the organization. The scope of the automation claim is specific: the agent produces infrastructure code as part of the described migration workflow. The post does not present the code generation step as a measurement of every other task involved in moving an application.

The post adds that AgentCore Policy evaluates the IaC Agent’s tool calls against Cedar rules before execution. This is another part of the implementation’s sequence: the agent receives shared context, generates code with approved modules and patterns, and has its tool calls checked against rules before they run. These details matter when interpreting the reported speed of generation, because the workflow includes more than a prompt and a generated file.

### Governance and operations after cutover

The Migration Intelligence and Governance Agent aggregates information from Jira, Confluence and Webex. For the automated updates and ticket creation described in the post, human approval is required before execution. The agent’s ability to gather information therefore sits alongside an explicit approval step for those actions. Keeping that condition in view gives a more precise account of what the post means by automation in migration governance.

After cutover, the SRE Agent is described as monitoring CloudWatch metrics, application performance data and historical patterns. Its role extends the account beyond preparation and migration tracking to the period after an application moves. Taken together, the four agents cover intake, infrastructure code, program information and monitoring after cutover. The post places these custom agents alongside AWS Transform for migration and modernization work and AWS DMS for database migration.

### What the reported time reduction covers

For this specific implementation, AWS reports that IaC development fell from 3–4 weeks per application to minutes of automated generation. The post attributes the comparison to internal project tracking data. It is a result reported for the infrastructure code development step in this program, so its scope should remain attached to that step and those project records.

The practical thread through the account is the transfer of application information. Documents and dependency records lead to a target architecture; shared context makes that architecture and its mappings available to the IaC Agent; policy checks its tool calls; program information is drawn together from work systems with approval before the specified updates and tickets are executed; and the SRE Agent watches operating data after cutover. That chain explains how AWS describes coordinating the agents across a migration program of more than 300 applications, while keeping the reported outcome tied to the implementation that produced it.