This page is the current overview of the system. The downloadable PDFs are the original April 2026 paper, which documented 53 tools across 10 domains; the sections below describe how the agent has grown since — to 117 tools across 27 categories, a second LLM backend, scheduled autonomous operation, and a portable manifest.
Problem
Managing cloud infrastructure means constant context-switching between the container orchestrator, metrics, cost tooling, log queries, and infrastructure-as-code. Manual investigation across multiple environments and regions is time-consuming, error-prone, and scales poorly with the number of services.
Solution: a natural-language operations agent
The agent exposes infrastructure through a natural-language interface backed by a tool-use agentic loop (up to 30 iterations per query). Ask a question in plain English; the agent selects and calls tools, reads the results, and returns an investigated, actionable answer. Two design choices from the original paper still anchor the system: read-only by default and learning without fine-tuning.
What is new is the provider-swappable LLM backend. The agent runs on either a managed in-account model (AWS Bedrock — Amazon Nova Pro) or an external, higher-reasoning model (a Claude endpoint), selected per invocation. Routine, high-volume queries use the cheaper in-account model; complex analysis can be routed to the stronger one. All infrastructure data stays within the account regardless of backend.
From 53 tools to 117
The original paper documented 53 tools across 10 domains. The agent now carries 117 tools across 27 categories — the growth is not padding but new operational surfaces the team kept reaching for. A representative slice of what was added:
| Capability | What it does |
|---|---|
| Budget Guardian | Real-time spend vs budget with end-of-month forecast, cost-anomaly detection (daily cost vs 7-day rolling average, flags >30% spikes), per-service attribution, and a savings finder (Spot eligibility, right-sizing, reserved-capacity gaps). |
| Cross-Region Failover Validator | Confirms the secondary region is in sync and ready to take over — version parity, replication lag, and service health rolled into a single readiness score (see below). |
| Tagging Compliance Engine | Scans resources for missing required tags, reports a compliance score and worst offenders, and applies fixes — dry-run by default. |
| Runbook Executor | Context-aware incident triage plus built-in multi-step runbooks with go/no-go gates (see below). |
| ECR Lifecycle Manager | Finds stale, untagged, and vulnerable container images; proposes retention policy and vulnerability counts. Auto-deletion is limited to untagged images past a long age threshold. |
| Connection Tunnel Manager | Opens SSH/SSM tunnels to managed data stores (document DB, message broker, relational DB) via bastion + Session Manager — key retrieval, port management and credentials handled from a natural-language request. |
| Dashboards & security posture | Generates metric dashboards on demand and scans security posture across the account. |
A composite readiness score
The failover validator is a good example of turning a vague question ("are we ready to fail over?") into a number. It computes a 0–100 failover readiness score from three weighted components, so a single value tells you whether the secondary region can take production traffic:
| Component | Weight | Check |
|---|---|---|
| Version parity | 40 pts | Deployed image tags match between primary and secondary region |
| Replication lag | 30 pts | Global-cluster replication lag within threshold (full score under a few seconds) |
| Service health | 30 pts | All secondary-region services running at their desired task count |
The scoring approach generalizes: any "are we ready?" question with several independent signals benefits from a weighted composite that degrades gracefully, rather than a binary that hides which dimension is failing.
Runbooks with go/no-go gates
Diagnosis and remediation are codified as runbooks rather than left to ad-hoc prompting. Asking the agent to diagnose a service triggers automatic triage — service health, recent error logs, and metrics — and yields a diagnosis plus a recommended runbook. Built-in runbooks include:
service_unhealthy— health → logs → metrics → recent deploys → roll back or scale.high_error_rate— error logs → identify pattern → dependency health → alert or remediate.database_pressure— DB metrics → connection count → replication lag → scaling recommendation.cost_spike— identify driver → runaway tasks → autoscaler state → recommendation.deployment_validation— health, error-rate and latency comparison → auto-rollback if degraded.
Every runbook executes step by step with go/no-go gates and runs dry by default; the mutating step happens only after explicit confirmation.
Interactive — and autonomous
The agent is no longer only a co-pilot you talk to. It also runs unattended as a set of scheduled command modes that execute checks and report to a chat channel:
| Mode | Cadence & behaviour |
|---|---|
budget_check | Daily — alerts if any environment exceeds 80% of monthly budget, or on a cost anomaly. |
ecr_cleanup | Weekly — reports stale images; auto-deletes only long-untagged ones. |
failover_check / security_scan / tagging_audit | Scheduled posture checks with a scored report. |
drift / report / weekly_cost / monitor | Drift detection, health and cost summaries on a cadence. |
remediate | Guarded auto-remediation — still gated for anything that mutates state. |
The same tools power both paths: an engineer asking a question interactively, and a scheduled job posting a report while everyone sleeps.
Adaptive learning
The agent still gets better over time without model fine-tuning:
- Learning engine — extracts insights from every tool result (non-blocking).
- Baseline tracker — tracks CPU, memory and cost baselines per service and flags deviations automatically ("this service usually sits at 30% CPU; it has been at 70% since this morning").
- Feedback collector — incorporates user approvals, rejections and corrections.
- Playbook store — saves successful multi-step investigations as reusable templates.
Security by design
The safety posture scales with the tool count — and matters more now that some tools can mutate infrastructure:
- Read-only default — write operations are blocked unless explicitly enabled.
- Dry-run by default — every mutating tool (tag fixes, retention enforcement, runbook steps, remediation) proposes before it acts.
- Approval gates — infrastructure-changing actions require human confirmation.
- Secret masking — credentials are redacted before reaching the model.
- Least privilege & in-account processing — minimum permissions per service; data does not leave the account.
- Full audit trail — every tool call and decision is logged.
From bespoke tool to portable framework
The most consequential change is not a feature — it is that the agent stopped being tied to one team's stack. Its knowledge of environments, accounts, regions and paths now lives in a single declarative manifest (.infra-agent.yaml), not in code. Pointing it at a different infrastructure is a config exercise, not a fork:
cloud_provider: aws | gcp | azure · iac_tool: terraform | pulumi | cloudformation | bicep | cdk · compute_platform: ecs_fargate | kubernetes | cloud_run | app_service
A quickstart wizard generates the manifest interactively, templates cover common stacks, and a porting guide walks through adapting the tools to a different cloud or IaC tool. What began as an internal operations co-pilot became a framework another team can adopt in an afternoon.
Production results
The efficiency numbers from the original evaluation still hold — the agent turns multi-hour investigations into single-digit minutes:
| Task | Manual | Agent | Reduction |
|---|---|---|---|
| Cross-env cost optimization | 2–4 hours | 2 min | 98% |
| Drift detection (all envs) | 1–2 hours | 45 sec | 99% |
| Incident root cause analysis | 30–90 min | 3 min | 95% |
| Environment parity check | 45–60 min | 30 sec | 99% |
| Failover readiness check | manual, error-prone | one scored report | — |
Operating cost remains in the low tens of dollars a month, dominated by LLM calls; routing routine queries to the cheaper in-account model keeps it there even as the tool count more than doubled.
Technology stack
AWS Bedrock (Nova Pro) External Claude endpoint AWS Lambda (Python 3.12) DynamoDB EventBridge Scheduler Terraform ECS / DocumentDB
The design thesis is unchanged from the original paper, only proven at larger scale: give operations a natural-language interface, keep it read-only and dry-run by default, let it learn from its own results — and make its knowledge of the environment declarative, so the same agent serves any stack. The PDFs above capture the foundational architecture, learning system and security model in full.