The best agent use cases may be the playbooks your teams already run. AWS shows it with cloud migration

Ask where agents should go first and many teams look for open-ended problems that seem to need intelligence. The better answer is often the opposite: long, tool-heavy work that people already run from a playbook, with known steps, known checks and known owners. Cloud migration is a textbook case, and AWS published an architecture for it on October 1.

What AWS describes

The post, by Nikhil Jha, Kaushal Agrawal, Tarun Tarun and Vyasamaharshi Garigipati, lays out four agents on Amazon Bedrock AgentCore, built with the Strands Agents SDK:

• Intake agent. Reads migration inputs from documents through MCP tools and produces a target architecture.
• Infrastructure-as-code agent. Generates infrastructure code by composing approved internal modules, rather than writing infrastructure from scratch.
• Migration intelligence and governance agent. Produces portfolio reporting, assessments and governance views across applications.
• SRE agent. Monitors workloads after cutover and handles automated remediation.

The plumbing is AgentCore: Runtime, Gateway, Memory for session state and shared context across agents, Identity for authentication, Policy enforcing Cedar rules, and Observability. Amazon Bedrock Guardrails block non-compliant outputs. Database and server moves run through AWS DMS and AWS Transform. The authors state that automated actions require explicit human approval before execution.

The post reports that infrastructure code development dropped from three to four weeks per application to minutes, across a portfolio of more than 300 applications, citing internal project tracking. That is a self-reported figure from the authors’ own engagement, not an independent benchmark.

Why migration suits agents

1. Intake: read inputs, propose target
2. Architect approves target
3. IaC from approved modules
4. Pipeline checks and approval
5. Cutover with rollback plan
6. SRE agent watches, proposes fixes

• Plan: Intake: read inputs, propose target · Architect approves target
• Build: IaC from approved modules · Pipeline checks and approval
• Run: Cutover with rollback plan · SRE agent watches, proposes fixes

Agent workHuman approval gate

Decomposition already exists. Discovery, design, build, cutover and operate are standard phases. Each agent gets one phase, which keeps its tools and permissions narrow. This is the first test in our framework for finding agent-ready work: an existing process with clear steps.

The output can be checked. Infrastructure code goes through the same pipeline, policy checks and reviews as code written by people. Composing approved modules is a strong design choice: the agent assembles from parts the platform team already trusts, so the review is about choices, not about every line.

State is long-lived. Migrations run for weeks. Shared memory across agents is what lets the governance agent report on the whole portfolio. It also means that memory holds architecture details and inventories, which deserve the same access control as the CMDB.

Policy sits outside the agents. Cedar rules in AgentCore Policy are evaluated by the platform, not by the model. That is the right place for “this agent may not touch production networking,” as we argued in our analysis of agent containment.

What is missing, and what you must add

Rollback. The post does not discuss rollback explicitly. In migration, rollback is the control that matters most on cutover day. Write it into the playbook before any agent touches cutover steps: what triggers it, who decides, and how long it takes.

Change management. For U.S. public companies, migrating systems that support financial reporting is a change under SOX IT general controls. Agent-generated infrastructure code and agent-proposed remediations need the same tickets, approvals and evidence as human changes.

The SRE agent’s authority. Automated remediation after cutover is where autonomy needs the most care. The same permission ladder applies as in AWS’s own DevOps Agent: read freely, propose generously, act only with an explicit grant.

What to do now

1. Pick a playbook your teams already run (migration, onboarding, patching, access reviews) rather than an open-ended problem.
2. Give each agent one phase with its own tools and permissions.
3. Constrain generation to approved building blocks where you can: modules, templates, runbooks.
4. Put human approval at phase boundaries and record it as evidence.
5. Write rollback and stop conditions before automating any step that changes production.
6. Measure per phase: time saved, rework rate, and defects caught at each gate.

The bottom line

The AWS design works for a reason that has little to do with AI: migration was already a disciplined, checkable sequence. Agents speed up each step without changing who decides between steps. Look for that shape in your own operations before looking for problems that only seem to need intelligence.