AWS AgentCore multi-agent pipeline cuts infrastructure-as-code work from weeks to minutes

A four-agent migration assembly line

According to dev.to, AWS Professional Services has published production figures for a multi-agent workflow that reduces infrastructure-as-code development from weeks to minutes. The system, built on Amazon Bedrock AgentCore primitives, splits a cloud migration into four specialist roles: a discovery agent that scans existing infrastructure and builds dependency graphs, an IaC generation agent that converts findings into Terraform or CloudFormation templates, a portfolio governance agent that validates output against policy and budget baselines, and a post-migration operations agent that handles drift detection and remediation.

Each agent runs with tools scoped to its own domain. The discovery agent cannot deploy anything, and the generation agent has no access to production credentials.

Handoffs through artifacts, not direct calls

The orchestration design is the notable part. Agents never invoke one another directly. Instead, each writes structured output (JSON containing resource metadata, dependencies and migration-readiness scores) to S3, updates a migration manifest stored in DynamoDB, and publishes an EventBridge event. The next agent in the chain subscribes to that event type and reads its input from the bucket.

The manifest acts as the single source of truth, tracking the current stage, pointers to each agent's output, governance validation results, and deployment state such as a Terraform state file location or CloudFormation stack ARN. Because coordination happens through immutable S3 objects and DynamoDB state transitions, there are no circular dependencies between agents. When the governance agent rejects a template, it resets the manifest stage back to generation and records the rejection reasons; the generation agent reads that feedback and produces a new version.

Governance as the only blocking checkpoint

The governance agent is the sole participant able to halt a migration. It estimates projected monthly spend through the AWS Pricing API, scans templates with tools such as checkov or tfsec to catch misconfigurations, and verifies that resources match tagging, encryption and network segmentation rules. Any failed check stops the workflow until the generation agent resolves it. Per dev.to, AWS reports that generated IaC passes governance on the first attempt roughly 60% of the time, and typically needs two or three iterations to clear every policy.

Least privilege by design

The dev.to write-up includes a permission breakdown across the four agents. Only the operations agent holds deployment rights, and even those arrive through time-limited credentials that expire after deployment, with post-migration monitoring running under a separate read-only role. Discovery and generation agents operate in read-only or generate-only modes. This separation contains the damage if the generation model produces invalid or non-compliant templates, since nothing reaches production without passing the governance gate.

Deployment shape and failure handling

Each agent is deployed as a Lambda function orchestrated by AWS Step Functions, which supplies retry logic. When a function hits a 15-minute timeout, Step Functions retries up to three times with exponential backoff; if an agent fails to update the manifest within that window, EventBridge routes the failure to a dead-letter queue handler.

Handoffs are instrumented through CloudWatch Logs Insights and X-Ray, with agents emitting structured JSON logs that include project ID, stage, status, duration and output location. The agents themselves are Bedrock Agents running Claude 3.5 Sonnet as the foundation model, each with its own instruction set and tool definitions, including documentation lookup for template generation.

Why it matters

Most multi-agent demonstrations stumble on the unglamorous parts: routing, state management and failure handling. This design offers a workable reference pattern, with event-driven handoffs through durable artifacts, a manifest as the coordination point, and a policy gate that treats model output as untrusted until validated. The reported 60% first-pass governance rate is the honest number here: the model frequently gets it wrong on the first try, and the architecture is built around that expectation rather than assuming away hallucinated templates. For teams building agent systems that touch real infrastructure, the IAM scoping and the rejection-feedback loop are more instructive than the underlying model choice, and the pattern should translate to other orchestration stacks beyond AWS.