AWS Orchestrator Capabilities

This page covers what the AWS Orchestrator can do — the workflows it supports, the quality rules it enforces, and the governance model that keeps your infrastructure safe.

---

What it generates

Every module produced by the AWS Orchestrator is a complete, production-ready directory. The exact file set depends on the service — the planner's skill blueprint decides what's needed.

Core files (always generated)

File	Purpose
main.tf	Resource definitions with security best practices
variables.tf	Typed, validated, documented variables — no hardcoded values
outputs.tf	All useful outputs with try() for conditional resources
versions.tf	Provider and Terraform version constraints
locals.tf	Computed values and tag merging
README.md	Usage example, inputs table, outputs table, requirements

Conditional files (generated when the service needs them)

File	When Generated
iam.tf	Services requiring extensive IAM roles (EKS, Lambda, ECS)
policies.tf	IAM policies, SCPs, permission boundaries
security_groups.tf	Services with complex security group rules (EKS, ALB, RDS)
data.tf	Data sources — AMI lookups, SSM parameters, existing VPCs
templates.tf	User-data scripts, Helm values, rendered configs

Example output for an S3 bucket module:

workspace/terraform_modules/s3/
├── main.tf           # S3 bucket + encryption + versioning + lifecycle
├── variables.tf      # Typed variables for all configurable properties
├── outputs.tf        # Bucket ARN, ID, domain name with try() guards
├── versions.tf       # AWS provider >= 5.40.0
├── locals.tf         # Tag merging, computed naming
├── policies.tf       # Bucket policy for cross-region replication
└── README.md         # Complete usage example with inputs/outputs tables

---

Generation quality rules

The agent enforces strict coding conventions through hardcoded prompt regulations — these are not suggestions, they are non-negotiable rules the generator must follow:

Rule	Implementation
Never hardcode values	Regions, account IDs, and credentials are always variables
Provider version locking	>= x.y.z constraints in versions.tf — prevents breaking API updates
Merge tagging	Every resource gets merge({"Name" = ...}, var.tags, var.<resource>_tags)
Conditional resources	count for simple on/off guards, for_each for collections
Safe outputs	try(resource[0].id, null) for resources guarded by count
Variable documentation	Every variable description must be a non-empty string
Security enforcement	CIS benchmarks, least-privilege IAM, encryption at rest, VPC flow logs
No bundling	Generator writes the exact files declared in the skill — never bundles everything into main.tf

---

AWS service coverage

The AWS Orchestrator supports any service in the AWS Terraform provider. It doesn't have a hardcoded list — the planner researches each service dynamically via the Terraform Registry MCP server.

Commonly generated modules include:

Category	Services
Networking	VPC, Subnets, NAT Gateway, Transit Gateway, Route53
Compute	EC2, EKS, ECS, Lambda, Auto Scaling Groups
Storage	S3, EFS, EBS
Database	RDS, DynamoDB, ElastiCache, Aurora
Security	IAM, KMS, Security Groups, WAF
Application	API Gateway, CloudFront, ALB, NLB
Monitoring	CloudWatch, SNS, SQS

---

Workflow: New Module

The full pipeline for generating a new Terraform module:

Step-by-step

Step	Agent	What Happens
1	Coordinator	Checks if /skills/{service}-module-generator/SKILL.md exists and is current
2	tf-planner	Runs 3-phase pipeline: requirements → security → execution planning → writes SKILL.md
3	tf-skill-builder	Creates skill files — skipped if planner already wrote them
4	tf-generator	Reads SKILL.md and references, writes all .tf files to virtual filesystem
5	Coordinator	Calls sync_workspace to materialise files to real disk
6	tf-validator	Runs terraform init -input=false, fmt -check, validate in sandbox
7	Coordinator	If INVALID: re-dispatches generator with errors → sync → validate again
8	Coordinator	If VALID: triggers Commit Gate (mandatory HITL)
9	github-agent	On approval: commits files via GitHub MCP. On "keep local": reports paths
10	Coordinator	Triggers Next Steps Gate (mandatory HITL): generate another, update, or done

---

Workflow: Update Module

The pipeline for modifying an existing module on GitHub:

Step	Agent	What Happens
1	update-planner	Fetches current module from GitHub, analyses structure, produces change plan
2	tf-updater	Fetches files via GitHub MCP, applies surgical edits (never full rewrites)
3	Coordinator	Calls sync_workspace
4	tf-validator	Validates the modified module
5	Coordinator	If INVALID: re-dispatches updater with errors
6	Coordinator	If VALID: triggers Commit Gate → Next Steps Gate

Key difference from new modules: the updater preserves existing formatting and conventions. It only touches files that need changing and tracks file SHAs for clean GitHub commits.

---

The skill system: how the agent avoids hallucination

The skill system is the core mechanism that prevents the generator from hallucinating provider configurations:

The generator reads the skill blueprint — not its training data — for:

• Which .tf files to create
• Exact resource arguments and types
• Variable schemas with defaults and validation
• Output definitions
• Provider version constraints

This means the generated code uses the latest provider API, not stale patterns from the model's training cutoff.

---

Validation & self-healing

The validation loop is designed to catch and fix errors automatically — but with guardrails to prevent infinite loops:

Triple-check validation

terraform init -input=false -no-color
terraform fmt -check
terraform validate

Self-healing flow

1. tf-validator runs the triple-check on generated files
2. If errors are found → structured error details are returned (INVALID: [file:line: error])
3. Coordinator re-dispatches tf-generator with the error context
4. Generator fixes the issues and writes corrected files
5. sync_workspace → tf-validator runs again
6. If it fails again after retry, the coordinator reports errors and stops — no infinite loops

Failure guards

Guard	Limit	Behavior
write_file failures	3 attempts	Generator stops and returns FAILED with error details
execute path errors	3 attempts	Validator stops and returns INVALID: directory not found
Total write calls	20 (middleware)	Middleware forces stop with error message
Total tool calls	60 (middleware)	Middleware forces graceful termination

---

Human-in-the-Loop governance

Infrastructure changes are irreversible. A bad terraform apply can take down production. So the agent doesn't just generate and commit — it pauses at critical gates.

Mandatory gates (never skipped)

Gate	When	What it asks
Commit Gate	After validation passes	Push to GitHub or keep local? Which repo and branch?
Next Steps Gate	After task completion	Generate another module? Update an existing one? Done?
Destructive Ops	Before deleting modules or force-pushing	Explicit human approval

Optional gates (agent's discretion)

Gate	When	Example
Ambiguous Requirements	Request is vague or has multiple valid interpretations	"Create a VPC" → which region? How many AZs?
Cost-Sensitive Decisions	Architecture choice significantly affects cloud costs	NAT gateway per AZ vs. shared, dedicated vs. shared tenancy

Self-improving policies

The HITL policy lives in /memories/hitl-policies.md. The coordinator reads it at the start of every session. If it discovers a new situation that should require human input, it updates the file — so the system gets smarter over time.