InfraAgent (chat to approved Terraform change)
TL;DRInfraAgent turns a request typed in Lark, Slack or another team chat app into a reviewed, approved, applied and merged Terraform pull request. The engineer's only action is the approval.Two AI agents on Amazon Bedrock (Claude): a chat agent in n8n clarifies the request, checks feasibility and writes a plain-language spec the requester confirms; a code agent (Claude Code GitHub Action) writes the Terraform and revises it for review comments and failing checks.The model reads and writes; code and the platform decide what may happen: tested gates, branch protection, a merge gate (secret scan, Trivy, PathGuard), and Atlantis as the only path to AWS. No job database.Built on AWS and deployed into the customer's own account and GitHub organisation, in a high-availability or a standard tier.Started 2026-07-28, ongoing; the full loop ran end to end on a sandbox on 2026-10-26. Headline target: median time from request to merged change under 2 hours.
1. Overview
What it is. InfraAgent turns an infrastructure request typed in a team chat into an approved, applied and merged Terraform pull request. A requester @-mentions the infra bot in Lark, Slack or another team chat app. A chat agent on Amazon Bedrock clarifies the request and shows a plain-language spec, which the requester confirms. A code agent writes the Terraform and opens a pull request in the customer's GitHub organisation, and revises it for review comments and failing checks. When an engineer approves, Atlantis applies the change to the target AWS account and merges the pull request, and the bot reports back in the thread.
The problem it solves. Infrastructure changes queue behind the few engineers who know Terraform and AWS, so simple requests wait days. Letting AI change the cloud on its own is fast but unacceptable: a wrong write to production is a risk nobody signs off. InfraAgent removes the queue without removing the human: the AI does the clarification, the coding and the revisions; an engineer only reviews and approves; nothing reaches AWS except through the approved pull request.
Who uses it. Requesters are internal staff of the customer, engineers first and non-engineers by design: the chat side assumes no Terraform literacy. Approvers are members of the customer's engineers team on GitHub.
2. Timeline
Item | Value |
Start | 2026-07-28: AI agent proof of concept integrated with a Lark bot, raised as action A2 in the weekly meeting |
End | Ongoing |
Date | Milestone |
2026-07-28 | AI agent PoC with a Lark bot raised (weekly meeting, A2); research concludes that n8n is the right orchestrator for the chat side |
2026-08-04 | n8n deployed on AWS (Amazon Elastic Container Service (Amazon ECS) on AWS Fargate, Amazon Relational Database Service (Amazon RDS), Elastic Load Balancing (ELB) Application Load Balancer (ALB)) with a live Lark bot answering through Amazon Bedrock |
2026-08-08 | First design document for end-to-end infra job automation |
2026-08-13 | Observability: n8n OpenTelemetry traces and per-workflow Amazon Bedrock cost through application inference profiles, in Grafana Cloud |
2026-09-02 | Product pitch |
2026-09-06 to 09-27 | Ideation and inception (requirements, architecture, contracts); team review of the decisions on 2026-09-14 |
2026-10-16 | v1 scope and architecture agreed (ADR-0020, ADR-0021, ADR-0023); implementation tickets cut |
2026-10-18 | Sandbox repository onboarded; GitHub and Atlantis behaviour verified by hand (Checkpoint V) |
2026-10-21 to 10-22 | Internal trial with colleagues on the sandbox |
2026-10-23 | Job lifecycle redesigned from the trial's root causes (ADR-0024) |
2026-10-26 | Live test: requests in English and Chinese, refusals of unsafe requests, and a request taken from chat to a pull request applied and merged by Atlantis |
3. Architecture
InfraAgent is powered by AWS and deployed into the customer's own account and GitHub organisation. Two deployment tiers run the same software; they differ only in resilience and cost.
3.1 High-availability deployment
Two AWS Availability Zones (AZs). The ALB, the Amazon Virtual Private Cloud (Amazon VPC) NAT gateways, the n8n workers, Amazon ElastiCache (Redis OSS) and Amazon RDS span two AZs. n8n runs in queue mode: a main instance takes webhooks and schedules, Redis holds the job queue, and workers in both AZs execute workflows, so a worker or an AZ can fail without losing events.
Private subnets. n8n, Redis, Amazon RDS and Atlantis have no public IP; outbound calls to the chat platform, GitHub and Amazon Bedrock leave through NAT gateways.
Edge. Amazon Route 53 resolves the bot hostname, AWS WAF filters inbound traffic, and the ALB terminates TLS with an AWS Certificate Manager (ACM) certificate. The ALB routes chat and GitHub webhooks to n8n and GitHub webhooks to Atlantis.
State. Amazon RDS for PostgreSQL Multi-AZ holds n8n's workflows, credentials and executions; there is no InfraAgent job database (see 3.5).
Atlantis runs as an Amazon ECS service on AWS Fargate; Amazon ECS reschedules it in either AZ.
3.2 Standard deployment
The cost-optimised tier keeps the same loop on one n8n task, a single-AZ encrypted Amazon RDS instance and Atlantis on AWS Fargate Spot, in public subnets with ingress restricted by security groups. Restarts lose at most an execution in progress: the next event re-reads the thread and the pull request (NFR6). It suits customers with a low request volume; the step-up to the high-availability tier changes infrastructure only.
3.3 Components
Component | Runs on | Does | Holds |
Chat app | Lark, Slack or another team chat app | The infra bot's identity and event subscription | Webhook subscription |
Chat agent | n8n workflow calling the Amazon Bedrock Converse API, signed with n8n's task role | Clarifies, resolves the target repository, checks feasibility against the repository's capability profile, writes the spec | No state: re-reads the thread on every event |
n8n workflows | Amazon ECS on AWS Fargate | Intake, confirm, report and a daily scan; routes every event to the next step | Chat credentials and the relay App key, in n8n's encrypted credential store |
Gates | TypeScript with Given/When/Then tests, bundled into n8n Code nodes or run as reusable GitHub workflows | Every deterministic safety rule: who may confirm, which repositories are onboarded, who may trigger a revision or an apply, the fix cap, refused paths | Nothing |
Relay GitHub App | GitHub | Reads onboarded repositories, receives their webhooks, dispatches the code agent | Read and dispatch only |
Code agent | Claude Code GitHub Action in a reusable workflow, called by each onboarded repository; Amazon Bedrock through GitHub OIDC | Opens the pull request and revises it | The agent App token for the run; no workflows permission |
Merge gate and PathGuard | Reusable GitHub workflows | terraform fmt, validate, init -lockfile=readonly, gitleaks secret scan (no waiver), Trivy at HIGH and CRITICAL, refused-path check | Nothing |
Approval workflow | Reusable GitHub workflow, no model | Turns an engineers-team approval of the head commit into atlantis apply | The agent App token for the run |
Atlantis | Amazon ECS on AWS Fargate | Plans, applies, merges | AtlantisExecutionRole in each target account |
3.4 Security model
Two credential sides. The side that reads chat (n8n) can read repositories and dispatch the code agent, and cannot push, comment on, approve or merge a pull request. The side that writes code (the code agent) cannot read chat. The confirmed spec is the only chat-derived content that crosses.
No credential that changes infrastructure outside Atlantis. n8n's task role and the code agent's OIDC role can invoke Amazon Bedrock and nothing that changes AWS. No model API key is stored anywhere.
The platform enforces the gates. Branch protection, "dismiss stale approvals on new commits", Atlantis apply_requirements: [approved, mergeable] and a ruleset that lets only Atlantis merge. An approval binds the commit: any later push removes it.
Reach is bounded by onboarding. The agent works only in repositories where the agent App is installed and the conformance set is present (Atlantis config, pinned caller workflows, CODEOWNERS, branch protection, committed lock file). The code agent cannot modify .github/workflows/.
Applies run with administrator rights.AtlantisExecutionRole has AdministratorAccess in each target account; blast radius is controlled by which repositories and accounts are onboarded and by human approval, not by path-scoped privilege.
Secrets. AWS Secrets Manager for n8n's encryption key, database and chat-app credentials; the agent App key is an organisation Actions secret visible only to onboarded repositories.
3.5 Data
There is no InfraAgent database. A job's record is the chat thread (conversation, the spec card the requester confirmed, the status card) and the pull request (confirmed spec, job block, commits, reviews, Atlantis plan and apply output). The job's state is derived from these by one deterministic function, so every component decides from the same facts and a duplicate event cannot open a second pull request. No raw chat transcript is stored.
3.6 Operations
One OpenTelemetry trace per job across n8n and the code agent, exported to Grafana Cloud; per-workflow Amazon Bedrock token use and cost through application inference profiles.
Alerts on the silent failure modes: an apply not completed within an hour, a reminder sent, the fix cap reached, a failed n8n execution.
A daily scan reminds about agent pull requests that wait too long and flags an apply that never completed.
Rollback: revert the pull request; Atlantis applies the reverted state through the same approval path.
4. AI feature design
4.1 Chat agent: clarify, check feasibility, specify
Model. Anthropic Claude Sonnet 4.6 on Amazon Bedrock, through a cross-region inference profile in the customer's Region, called with the Converse API from n8n.
What the model decides. Whether a message in a job's thread is addressed to the bot, its intent (new request, clarification, status, amend, cancel, help, unrelated), the clarifying questions, the target repository when the match is unambiguous, and the plain-language spec.
What code decides. What may happen next. The model returns structured output only; code validates it, and invalid output is treated as "not for the bot". Only the requester can confirm a spec; a confirmed job cannot be re-specified in the same thread.
Feasibility before code. Each repository has a capability profile: its account and Region, the security policy the merge gate enforces, and what cannot be done there. The chat agent refuses infeasible requests before a spec exists and offers a compliant alternative (for example, a private Amazon Simple Storage Service (Amazon S3) bucket behind Amazon CloudFront instead of a public bucket).
Language. Replies, specs and cards follow the requester's language.
4.2 Code agent: write and revise Terraform
Model and runtime. Claude Code (anthropics/claude-code-action) on GitHub-hosted runners, with Claude Sonnet 4.6 on Amazon Bedrock through a GitHub OIDC role scoped to the agent's workflow and the customer's repositories.
Inputs. The confirmed spec, the job id and the thread link, plus repository instructions and a prompt versioned with the workflow and pinned by commit, so a target repository cannot change them.
Behaviour. Writes the change in the style of the files it edits, opens the pull request with the spec and a job block in its description, and revises for review comments (uncapped) and for failing plans or checks (at most three fix commits per pull request, counted from marked commits). It never acts after an apply; a failed apply is reported to the requester with Atlantis's output.
4.3 Responsible AI controls
Risk | Control |
Prompt injection from chat | No typed text passes a gate; the most injected text can do is shape a spec the requester must confirm with a button. Gates are tested code and do not consult a model |
A wrong or unsafe change | Human review and approval of the head commit; the merge gate fails closed on refused paths, secrets and high-severity findings; Atlantis applies only an approved, mergeable head |
The agent widening its own reach | No workflows permission; onboarding through a runbook; CODEOWNERS on the caller workflows |
Secret leakage | Secret scan on every diff with no waiver; no secret in logs, traces, chat or comments (tested by injecting a known token) |
Silent failure | Every user action ends in a visible outcome on the card and the pull request: done, waiting with a reason, or failed with a reason and a next step |
4.4 Evaluation
A scenario catalogue (63 scenarios across input form, intent, feasibility, roles, concurrency, failure and lifecycle) states the expected behaviour of each and how it is verified: contract tests for code, a scored example set replayed against Amazon Bedrock for model judgment, and conformance checks for GitHub and Atlantis. It runs before every release.
Gates and job-record code: unit tests with a 65% line-coverage floor on deterministic TypeScript.
Live tests on a sandbox repository, recorded with evidence.
4.5 Value
Speed. A request becomes a reviewable pull request in minutes instead of waiting for a free engineer; the target is a median of under two hours from @-mention to merged change.
Engineer time. Engineers review and approve instead of clarifying, writing, planning and applying.
Access. Staff without Terraform knowledge can request infrastructure in the chat they already use, in their own language.
Safety and audit. Every change is a reviewed pull request with the requester's confirmed spec, the approver and Atlantis's output on record; the same gate applies to hand-written and AI-written Terraform.
5. Metrics
Baselines are measured before go-live from the customer's recent infrastructure requests; actuals from the job record after go-live. The same definitions serve as the project's ongoing benchmark.
# | Metric | Definition and formula | Data source | Baseline | Target | Actual |
M1 | Lead time to change | Median time from the request message to the merged pull request, over merged jobs in a rolling 30 days, with sample size | Before: ticket or chat timestamp to merge time of the hand-written PR. After: job id (the request message) to merge time | TBD | Under 2 hours (NFR1) | TBD |
M2 | Engineer hands-on time per change | Before: engineer time to clarify, write, plan and apply. After: time from review request to approval, plus time on review comments | Before: time tracking or sampled estimates. After: pull-request review timestamps | TBD | TBD | TBD |
M3 | Self-service rate | Merged agent pull requests with no engineer-authored commit ÷ all merged agent pull requests | Pull request commits | n/a | TBD | TBD |
M4 | First-pass approval rate | Agent pull requests approved with no revision commit ÷ approved agent pull requests | Pull request commits and reviews | n/a | TBD | TBD |
M5 | Revisions per pull request | Review-driven and check-driven revision commits per merged pull request; share reaching the three-fix cap | Marked fix commits | n/a | TBD | TBD |
M6 | Apply success rate | Applies that succeed first time ÷ all applies | Atlantis apply comments | TBD | TBD | TBD |
M7 | Safety violations | Changes applied or merged without an approval of the head; refused-path changes merged; secrets exposed | Branch protection, Atlantis, merge gate, secret scan | n/a | 0 | TBD |
M8 | Scenario pass rate | Scenarios meeting their expected behaviour ÷ scenarios in the catalogue | Scenario catalogue run | n/a | 100% before release | TBD |
M9 | Cost per merged change | Amazon Bedrock cost (inference profiles) plus GitHub Actions minutes, per merged job | AWS Cost Explorer, Amazon CloudWatch, GitHub billing | n/a | TBD | TBD |
M10 | Adoption | Requests per month, distinct requesters, share of requesters outside the engineers team | Job records | n/a | TBD | TBD |
Comments