OpsAgents: Ten LangGraph Agents for Cloud and DevOps Work

Engineers keep asking the same thing about DevOps agents in different words: does something like this actually exist, where's the code and can it run today? Concepts only go so far, so the practical answer is OpsAgents, a set of ten AI agents for cloud and DevOps operations, built with LangGraph and Python. It runs both as a command-line tool and as an MCP server.

Beta notice: OpsAgents is in beta. Don't use it in production environments. Breaking changes can arrive without warning, and you use it at your own risk.

Design rules

A human confirms every destructive action. Scaling a deployment, applying Terraform or triggering a runbook all make the agent stop and ask before anything irreversible happens. It isn't a setting you can switch off, because production infrastructure shouldn't allow it.

State machines, not fragile prompt chains. Each agent is a directed graph where state moves through nodes. If a step fails midway, state is preserved and the agent can recover. With checkpointing, an agent survives a restart without losing progress.

Real integrations. The agents work against AWS Cost Explorer, CloudWatch, CloudTrail, IAM, SSM and EC2, run actual Kubernetes operations through kubectl, use Trivy for genuine CVE scanning and produce Grafana dashboard JSON you can drop into an existing stack. None of it is stubbed or mocked.

Several model providers. Claude, GPT-4, Gemini, Mistral and Ollama all work, and Ollama allows fully local, air-gapped runs. The framework doesn't depend on any one vendor.

Two ways to run it

In CLI mode, you launch any agent straight from the terminal, which suits ad-hoc operations, scripting and testing.

In MCP server mode, OpsAgents plugs into Claude Code, Cursor, Codex or OpenCode, so you can talk to your infrastructure like a teammate. Once the MCP server is configured in your editor, each agent becomes a tool the editor can call. You might ask it to scan the cluster for failing pods or to report on this month's AWS bill, and the right agent handles the request, with a confirmation prompt before it changes anything.

The ten agents

Cloud agents (AWS)

Infrastructure Provisioner. This one covers the full Infrastructure-as-Code lifecycle. Describe what you want in plain English, such as a public VPC with two subnets across availability zones, and it writes complete Terraform or CloudFormation. It then checks syntax and runs terraform plan, so you see exactly what will change before any resource exists, and applies only after interactive confirmation. Afterward it can audit the live AWS account and flag drift from what's in Git, which catches manual changes that bypass the IaC workflow.

• Natural language to full Terraform or CloudFormation, not just a skeleton
• Syntax validation and a dry-run plan before execution
• Apply with human confirmation
• Drift detection between live AWS state and Git-tracked configuration

Security and Compliance. Production AWS accounts pick up risk quietly. IAM policies loosen over time, security groups get opened for debugging and never closed, and S3 buckets end up misconfigured. This agent audits continuously instead of relying on occasional reviews. It looks for wildcard permissions in IAM policies and over-privileged credentials, finds EC2 security groups with public ingress (SSH open to 0.0.0.0/0 being the classic), and checks S3 buckets for missing encryption and public read access. Results are measured against the CIS AWS Foundations Benchmark, so you get severity ratings and not a bare list.

• IAM analysis covering wildcards, escalation paths and unused permissions
• Security group audits for public ports and overly open ingress
• S3 audits for encryption status and public access
• CIS benchmark comparison with severity

Cost Optimizer. AWS bills hold waste that nobody has time to hunt down by hand: unattached EBS volumes, EC2 instances idling at 3% CPU for months, Elastic IPs allocated to nothing, Reserved Instance coverage that drifts as the fleet changes. The agent queries Cost Explorer for spending reports, finds unused resources by type and region, suggests rightsizing for underused compute and points out where Savings Plans or Reserved Instances would cut spend. Each recommendation carries an estimated monthly saving.

• Cost Explorer queries by service, region and period
• Detection of unattached volumes, idle instances and unused Elastic IPs
• Rightsizing advice with estimated savings
• Savings Plan and Reserved Instance coverage analysis

Incident Response. After a production alarm fires, the first 15 minutes matter most. This agent starts the investigation in parallel, before a human is fully awake. It gathers every CloudWatch alarm currently in ALARM, queries Log Insights for recent errors and lists CloudTrail API calls around the time of failure, a combination that usually reveals what changed. If a standard SSM runbook fits, it can trigger it once you confirm. After resolution, it writes a structured markdown post-mortem covering timeline, root cause and mitigation.

• Alarm aggregation showing what's in ALARM, since when and which resources
• Root cause analysis from Log Insights plus CloudTrail history
• SSM runbook execution with approval
• Generated post-mortems

Architecture Review. Most teams check their design against the AWS Well-Architected Framework once at launch and rarely again. This agent keeps the review going. It discovers RDS databases, EC2 instances, load balancers, Lambda functions and S3 buckets without being told what exists, then draws Mermaid flowcharts of how they connect. It evaluates settings against Well-Architected pillars and flags gaps like missing multi-AZ deployment, RDS without automated backups and single-region designs where multi-region was intended.

• Automatic discovery, so no manual inventory is needed
• Mermaid topology diagrams built from live data
• Reliability, performance and cost pillar evaluation
• Specific findings on multi-AZ, backups and bottlenecks

DevOps agents (platform operations)

CI/CD Pipeline. Everyone has opinions about pipelines and nobody has time to tune them. This agent studies the codebase and generates tailored pipeline configuration instead of starting from a generic template. It detects the language, package manager and build system, then scaffolds GitHub Actions workflows with dependency caching, minimal permissions (OIDC instead of long-lived credentials) and sensible job separation. When a pipeline fails, it reads the logs and gives a precise diagnosis, not "the build failed" but something like a cache miss traced to a lockfile edit that left the cache key hash stale.

• Detection of language, package manager and build system
• Workflow generation with caching, OIDC and permission controls
• Failed-build diagnosis with a specific cause and fix

Kubernetes Operations. This agent behaves like a cluster administrator with full diagnostic and remediation powers, and it's probably the most useful one for on-call work. It summarizes the health of nodes, namespaces and system pods in one table. For failing containers it follows specific diagnostic paths for CrashLoopBackOff, OOMKilled and ImagePullBackOff by examining events and conditions. It writes YAML for Deployments, Ingresses and Services, and it can scale replicas or roll back directly, after confirmation.

• Cluster health summary in a single table
• Structured pod diagnostics for common failure states
• YAML generation for Deployments, Ingresses and Services
• Scaling and rollback with confirmation

Monitoring and Observability. Everyone agrees monitoring configuration matters and finds it tedious. PromQL syntax is unforgiving, Grafana dashboard JSON is verbose and Alertmanager routing trees are easy to get subtly wrong. This agent writes PromQL alerting rules for common signals such as error rate, latency percentiles and saturation, builds Grafana dashboard JSON with panel queries ready to import and drafts Alertmanager routing for Slack or PagerDuty. Given a target availability like 99.9% or 99.95%, it also computes the monthly error budget and maximum allowed downtime.

• PromQL templates for standard infrastructure signals
• Importable Grafana dashboard JSON
• Alertmanager routing for Slack and PagerDuty
• SLO math, including error budget and downtime allowance

GitOps and Release. This agent handles the release work that surrounds deployments: config files, changelogs, version bumps and rollback preparation. It scaffolds ArgoCD Application manifests with self-healing and pruning on, and creates Argo Rollouts configs for canary or blue-green releases, with AnalysisTemplates so promotion can be decided automatically. For releases, it bumps semver tags, builds changelogs from commit history and can open rollback PRs when a deployment needs to be reversed quickly.

• ArgoCD manifests with self-healing, pruning and sync policies
• Canary and blue-green Rollouts with AnalysisTemplates
• Semver bumps and changelogs from git history
• Rollback PR creation

Container and Image Security. Supply chain security isn't optional in 2026, and this agent does the scanning and hardening that should happen before any image reaches production. It audits container layers for CVEs with Trivy and reports severity and affected packages. It reviews Dockerfiles and refactors them with multi-stage builds to shrink the image, cache cleanup to avoid layer bloat and non-root users. It scans lockfiles (poetry.lock, package-lock.json, Gemfile.lock) for outdated or vulnerable dependencies, and for compliance it generates CycloneDX or SPDX software bills of materials.

• Trivy CVE scanning with severity ratings
• Dockerfile hardening
• Lockfile scanning for outdated and vulnerable packages
• SBOM output in CycloneDX and SPDX

Why LangGraph underneath

Several frameworks could have served here, among them LangGraph, the Claude SDK, the OpenAI Agents SDK, CrewAI and AutoGen. LangGraph won because its strengths line up with DevOps requirements.

Production workflows aren't linear. A security scan that finds a critical IAM problem has to route differently from one that finds nothing, and an incident investigation that can't pin down a root cause in the logs should escalate to CloudTrail. LangGraph's conditional routing handles that cleanly.

State persistence means an agent working through a complex incident survives a restart without losing its findings. Checkpointing lets you replay a workflow from any node with changed inputs, which is essential when you're debugging an agent that made a surprising decision. And human-in-the-loop support is part of the graph model itself instead of being bolted on. You decide which nodes need confirmation and the graph pauses there.

Lessons from building it

Three things weren't obvious until the agents existed:

• The confirmation step is everything. A well-placed prompt before destructive actions separates a useful agent from a dangerous one. Doing it properly means treating human approval as an architectural constraint, not a checkbox, which forces you to work out which nodes in each graph actually have side effects.
• State design is the hard part. Getting the agent logic to run is easy. Deciding what must persist, what stays temporary and how errors propagate takes iteration, and the Kubernetes agent went through three redesigns of its state before the diagnostic flow felt natural.
• Tools outweigh model choice. An agent is only as capable as its tools. Making the AWS tool functions return structured, consistent output paid off more than prompt tweaking, because a model reasons better when the data it receives is clean.

What comes next

This is a starting point and not a finished product. The agents cover the most common cloud and DevOps workflows, and plenty of ground remains. Directions under consideration include multi-cloud support with GCP and Azure agents, cost anomaly detection based on historical patterns instead of static thresholds, drift auto-remediation where the agent generates and applies the fix with approval, and tighter integration with the Claude Code and Cursor MCP flows.

How to contribute

You don't need to be an expert, only curious. The most useful help depends on who you are:

• DevOps or cloud engineer: run an agent against real infrastructure and report what broke, what output confused you and which workflow you expected it to handle. Real-world feedback is the most valuable input at this stage.
• Developer: pick any agent, read its graph definition and improve something, whether that's better error handling, a missing tool or a state field that should be tracked. The codebase is small enough to understand a whole agent in about 30 minutes.
• Newcomer to DevOps agents: the repository doubles as a learning environment. Fork it, run it locally with Ollama so there are no API costs, and read the code next to a general guide on DevOps agents. Opening an issue to ask a question counts as a contribution.
• Anyone with an idea for a new agent: open an issue describing the workflow. If something you do by hand today should be automated, say so. A Secrets Manager auditing agent, multi-cloud agents and a cost anomaly agent are all on the roadmap and open for someone to build.

Star the repo, open an issue or send a pull request. The aim is agents that hold up in production, built in the open.