AWS Professional Services just published production data on a multi-agent system that compresses infrastructure-as-code development from weeks to minutes.
The system chains four specialized agents (discovery, IaC generation, governance, operations) using Amazon Bedrock AgentCore primitives.
This is not a demo.
It is a deployed enterprise migration workflow with real customer proof points.
The interesting part is how AWS routes tasks between agents without creating circular dependencies, and how they instrument handoffs when a single migration spans four agents with different failure modes.
Architecture: Four Agents, One Workflow The system decomposes cloud migration into four agent roles: Discovery Agent: Scans existing infrastructure, builds dependency graphs, identifies migration candidates IaC Generation Agent: Converts discovered resources into Terraform or CloudFormation templates Portfolio Governance Agent: Validates generated IaC against organizational policies, cost budgets, security baselines Post-Migration Operations Agent: Monitors deployed resources, handles drift detection, executes remediation Each agent is a Bedrock Agent with tool access scoped to its domain.
The discovery agent cannot deploy infrastructure.
The IaC generation agent cannot read production credentials.
The governance agent has read-only access to policy repositories.
AgentCore orchestrates handoffs using a state machine pattern.
When the discovery agent completes a scan, it writes structured output (JSON schema with resource metadata, dependencies, and migration readiness scores) to an S3 bucket.
The IaC generation agent subscribes to that bucket via EventBridge and begins template generation only after the discovery agent marks the scan as complete.
State Management and Handoff Primitives The key orchestration primitive is a migration manifest stored in DynamoDB.
Each migration project gets a manifest with these fields: : Unique identifier for the migration : Enum (discovery, iac_generation, governance_review, deployment, post_migration) : Map of agent name to S3 URIs for structured outputs : Array of governance checks with pass/fail status : Terraform state file location or CloudFormation stack ARN When an agent completes its task, it updates the manifest and publishes an EventBridge event.
The next agent in the chain subscribes to that event type and reads the previous agent's output from S3.
This design avoids circular dependencies because agents never call each other directly.
They communicate through immutable artifacts (S3 objects) and state transitions (DynamoDB updates).
If the governance agent rejects IaC templates, it sets back to and writes rejection reasons to .
The IaC generation agent polls the manifest and regenerates templates based on the feedback.
Governance Agent: The Critical Checkpoint The portfolio governance agent is the only agent that can block a migration.
It runs a suite of validation tools: Cost estimation: Calls AWS Pricing API to project monthly spend for generated resources Security posture: Runs or against IaC templates to catch misconfigurations Compliance checks: Validates that resources match organizational tagging policies, encryption requirements, network segmentation rules If any check fails, the governance agent writes a structured rejection message to the manifest and halts the workflow.
The IaC generation agent must address all failures before the workflow can proceed.
This checkpoint prevents the common failure mode where automated IaC generation creates resources that violate organizational policies.
The governance agent acts as a circuit breaker.
Authorization Boundaries AWS uses IAM roles to enforce least-privilege access between agents: Agent Read Access Write Access Deployment Permissions Discovery Existing infrastructure (EC2, RDS, VPC) S3 (scan results) None IaC Generation S3 (scan results), policy repos S3 (IaC templates) None Governance S3 (IaC templates), policy repos, pricing API DynamoDB (va